You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issue
SystemFile assumes it's existance, and has limited use (issue #26) and without core properties (Attributes, Dates, Exists, etc) is slow and unusable.
Reason
A file's state is not static, it can change outside of the app at any time.
Proposal
The constructor of SystemFile should not assume or enforce anything. It shoudl simply return an object (or null).
The developer can then check for Exists, Attributes, and use the path manipulation properties even on none-existance files.
For example: systemFile.Filename or systemFile.Extention - these properties are very useful for path manipulation and are currently absent and also would not be available if the constructor of systemFile rejects none-existant files.
The text was updated successfully, but these errors were encountered:
The developer can then check for Exists, Attributes, and use the path manipulation properties even on none-existance files.
In #23, we're working on standardizing properties so properties from implementation can be consumed using a single common API.
It seems like you just need access to the underlying System.IO APIs given an instance of SystemFile or SystemFolder.
We try to provide this functionality in every implementation we make, so there's no need to add all these things to SystemFile directly. I recommend using the SystemFile.Path with System.IO APIs such as FileInfo.
For example,
varfile=newSystemFile("C:\file.txt");varfileInfo=newFileInfo(file.Path);// Access the data you needvarw=fileInfo.Attributes;varx=fileInfo.CreationTime;vary=fileInfo.Exists;varz=fileInfo.Length;
Issue
SystemFile assumes it's existance, and has limited use (issue #26) and without core properties (Attributes, Dates, Exists, etc) is slow and unusable.
Reason
A file's state is not static, it can change outside of the app at any time.
Proposal
The constructor of SystemFile should not assume or enforce anything. It shoudl simply return an object (or null).
The developer can then check for Exists, Attributes, and use the path manipulation properties even on none-existance files.
For example: systemFile.Filename or systemFile.Extention - these properties are very useful for path manipulation and are currently absent and also would not be available if the constructor of systemFile rejects none-existant files.
The text was updated successfully, but these errors were encountered: