Open jdpatterson opened 12 years ago
How about ExtantFile
and ExtinctFile
? ツ
In all seriousness, though, I noticed this, too. A few alternative antonym pairs—most of which aren't all that brilliant, either—for the sake of getting a brainstorm going:
To be explicit, each of those could give us, for example
FileSystemResource
=ExistentResource
∪NonexistentResource
, whereExistentResource
=File
∪Directory
∪Link
instead of the current
Resource
=ExistingResource
∪Nil
, whereExistingResource
=File
∪Directory
∪Link
.
I understand, of course, the value in keeping names short, so it's certainly worth looking for more concise alternatives that still adequately convey the concepts.
I definitely don't love Nil
. Way too generic. But I really think it needs to be something snappy.
Missing
vs. Existing
is frankly pretty good. But is it really right to say something is "missing" when there's nothing at that path? To me "missing" almost carries some kind of negative connotation...
Available
almost works for me, and I had considered it myself. I think Unused
might grow on me.
I see what you are saying about Missing. Actual / Available? EDIT: Of course that would be confused with the annotation actual.
After some time on http://thesaurus.com/browse/missing there has been no bolt of inspiration.
Present / Absent ? Like a school roll call. It reads well. Or Present / Available
I'm surprised at how ok Existing
/ Unused
feels, given that I wouldn't normally encounter them as polar opposites. Oh well, why fight it if it feels good?
Brainstorm continues below this (remarkably stylish) line...
You could abandon adjectives altogether and go for something like NoFile
, NotAFile
, NoResource
, or NotAResource
.
To be honest I don't understand why Resource
deserves to own linkedResource
, when a particular Resource
might not exist, let alone be a Link
. Or, for that matter, what purpose Resource
serves, other than being shorthand for ExistingResource|Nil
.
Now, that was probably just my ignorance of the design of the thing speaking, but if it did so happen to turn out that Resource
didn't offer much, perhaps the Nil
case could instead be addressed by a subclass of Path
instead—say, UnusedPath
, AvailablePath
, or NonexistentPath
—to house those createFile()
and createDirectory()
utility methods (and any other friends they might pick up in future). Methods that might or might not return an actual existent resource could then in general return ExistingResource|UnusedPath
instead of a Resource
to really drill in the notion that they're different kinds of things. It's certainly more verbose, but in my humble opinion would also make the client code clearer to read.
Too wacky/convoluted? Completely missing the point?
To be honest I don't understand why
Resource
deserves to ownlinkedResource
, when a particularResource
might not exist, let alone be aLink
.
Well, it lets you get those pesky links out of the picture conveniently, without having to switch.
Or, for that matter, what purpose
Resource
serves, other than being shorthand forExistingResource|Nil
.
It also has a path stuck on it.
perhaps the
Nil
case could instead be addressed by a subclass ofPath
instead.
Well, when you have a Path
, you don't know what there is underlying that. We don't need to go to the fs to construct a path in it. But the operations you can perform on Nil
s are supposed to be the operations you only perform once you've checked that there is nothing there already.
What about Free
?
On 12/06/2012, at 10:17 PM, Gavin King wrote:
Well, it lets you get those pesky links out of the picture conveniently, without having to switch.
And Nil is returned by a normal file? What happens here:
if (is Nil linked = normalFile.linkedResource) { linked.createFile() }
Out of curiosity, is your recommendation to always use attributes instead of 0 args methods? I mention it because I see in the doc for the file package that in one example you do use .resource() instead of .resource
And
Nil
is returned by a normal file?
No. I think perhaps I need to document what that operation does a little better. Or perhaps it could be a function instead of a method. If you have a File
you get a File
back. If you have a Link
you get something else back.
Out of curiosity, is your recommendation to always use attributes instead of 0 args methods?
No, the convention here is still "developing". Honestly resource
should probably be a method because it can return a different kind of thing when you reinvoke.
I mention it because I see in the doc for the file package that in one example you do use .resource() instead of .resource
Oops, that's a mistake.
I hadn't looked at ConcreteResource.linkedResource
, so I wrongly assumed that linkedResource
was only applicable in the case of a Link
, so it might therefore throw an exception or something equally unpleasant otherwise. Now I understand that it is designed to handle that common case where you don't want to care about the indirection that may or may not be happening (even before checking if the Resource
exists at all), I better understand the value of Resource
. Thanks!
Free
sounds nice enough, but it seems to imply that a file actually could be immediately created at the given path (without creating missing ancestor directories first) which is why I would favour something like Unused
.
Also (at a slight tangent) would it be better to have a type of UnknownResource
to express things like device files rather than having ConcretePath.resource
throw an exception in this case?
Also (at a slight tangent) would it be better to have a type of
UnknownResource
to express things like device files rather than havingConcretePath.resource
throw an exception in this case?
Yeah, I guess it would be better if Resource
were not an enumerated type, actually.
On 12/06/2012, at 11:44 PM, Gavin King wrote:
And
Nil
is returned by a normal file?No. I think perhaps I need to document what that operation does a little better. Or perhaps it could be a function instead of a method. If you have a
File
you get aFile
back. If you have aLink
you get something else back.
Oh yeah that makes a lot more sense. It seems to be a programming convenience which would suit being a function rather than a direct part of the core API.
BTW, its amazing to see how willing to discuss all this you guys are.
Just for the record re naming - I like the way Present and Absent read
if (is Present myResource) {…} if (is Absent myResource) {…}
Absent is less negative than Missing - it does always suggest that it should be there (def 2)
1. not in a certain place at a given time; away, missing (opposed to present): absent from class. 2. lacking; nonexistent: Revenge is absent from his mind.
Free has other connotations in the context of a file system such as free space (i.e. can I fit more in this file?).
BTW, its amazing to see how willing to discuss all this you guys are.
Can I second that? I really appreciate this. I'm sure there are plenty of pros and cons for a team working in this open manner, and that there's a fine line between potentially valuable community participation, and noise/nuisance. (I hope my/our involvement lands mostly in the former!)
Regarding Present
, Absent
, and Free
, I follow the rationale and I like it.
Just for the record re naming - I like the way Present and Absent read
if (is Present myResource) {…} if (is Absent myResource) {…}
Hah. Yeah, that does read pretty nice.
Just wondering if the changes discussed here will make it into the SDK?
I didn't even know this thread existed, but although late I wanted to say +1 to:
if (is Present myResource) {…}
if (is Absent myResource) {…}
@jdpatterson I'm not sure to be honest, we're all pretty busy right now getting ready for M4. But if you want to make a contribution and have some time on your hand I'm pretty sure @gavinking would welcome it :)
Just wondering if the changes discussed here will make it into the SDK?
I guess I'm still not totally happy with Present
and Absent
, though I agree that they're better than what we have currently. While these names read nice in a is
condition, they don't read so well as the type of an attribute or method...
Moving to M6.
Think we should get this rolling for 1.4? Maybe with the renamed
/aliased
concept from ceylon/ceylon#7233?
Hi Gavin, not sure the best place for inane amateur comments such as this but... The file API looks very clean and I can't wait to start using this in production. At first glance I wondered what was this Nil type and wondered if I had missed something from the ceylon docs as it seems such a generic name used for other purposes in other languages. I then saw that it is paired with ExistingResource to make creating missing resources easy.
I thought that names Missing and Existing (c.f. Nil and ExistingResource) might make your examples easier to read:
if (is Missing loc = filePath.resource) if (is Existing loc = filePath.resource)