Nil and ExistingResource names about ceylon-sdk HOT 19 OPEN

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:

• Existent vs. nonexistent
• Actual vs. nominal
• Present vs. absent
• Used vs. unused
• Taken vs. available

from ceylon-sdk.

To be explicit, each of those could give us, for example

FileSystemResource = ExistentResource ∪ NonexistentResource,
where ExistentResource = File ∪ Directory ∪ Link

instead of the current

Resource = ExistingResource ∪ Nil,
where ExistingResource = 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.

from ceylon-sdk.

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.

from ceylon-sdk.

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

from ceylon-sdk.

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?

from ceylon-sdk.

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.

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 for ExistingResource|Nil.

It also has a path stuck on it.

perhaps the Nil case could instead be addressed by a subclass of Path 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 Nils are supposed to be the operations you only perform once you've checked that there is nothing there already.

from ceylon-sdk.

What about Free?

from ceylon-sdk.

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

from ceylon-sdk.

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.

from ceylon-sdk.

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?

from ceylon-sdk.

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?

Yeah, I guess it would be better if Resource were not an enumerated type, actually.

from ceylon-sdk.

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 a File back. If you have a Link 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)

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?).

from ceylon-sdk.

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.

from ceylon-sdk.

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.

from ceylon-sdk.

Just wondering if the changes discussed here will make it into the SDK?

from ceylon-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 :)

from ceylon-sdk.

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...

from ceylon-sdk.

Moving to M6.

from ceylon-sdk.

Think we should get this rolling for 1.4? Maybe with the renamed/aliased concept from eclipse-archived/ceylon#7233?

from ceylon-sdk.