Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alternate special character selector names? #9

Open
dalehenrich opened this issue Apr 6, 2012 · 6 comments
Open

alternate special character selector names? #9

dalehenrich opened this issue Apr 6, 2012 · 6 comments

Comments

@dalehenrich
Copy link
Member

Damien Pollet suggested that we use the HTML names for the special character selectors. Here's the Wikipedia
List of XML and HTML character entity references.

I suppose it isn't a bad idea to use the "official" names of the characters themselves ...

@mkobetic
Copy link
Member

I don't mind changing the list to match some recognizable convention or standard as long as it includes all the characters we need it to. I can't find question mark on the wikipedia list. Is there a name for it?

@seandenigris
Copy link

+1 for using $- to replace $: (instead of $.).
I found the $. substitution confusing, and posted to the Metacello mailing list.

I thought it was a bug, and my initial question was "Some of the method files have one dot (e.g. project.st), others have two (e.g. development..st). Why is that?"

Now that I understand what's going on, I think $. just seems like a confusing substitution because it already has meaning in filenames, so the domains clash.

@mkobetic
Copy link
Member

I'd say using $. to replace $: is a separate issue, but I remember having the same first reaction until I talked to Travis and he pointed out that any keyword selector ending with a colon will translate to -.st suffix. Not very pretty either. Eventually I warmed up to the idea of using the dots.

@ottobehrens
Copy link

So sad, $: works so nicely on linux. Which means I can copy the selector in my image and just use locate <selector with $:>. Can't we just ditch that's doesn't like it? :-)

The only character that causes a problem on linux is /. Although .st and .st and some others need some special attention to work with on the command line, it still is workable (find | grep \ to find multiplication methods in the repo).

Will find | grep foo: not work on ?

(Sorry, not keeping track of what works on the different platforms.)

@dalehenrich
Copy link
Member Author

What was the origin issue with $: in file names ... I don't recall off hand ... I did use $: on the mac initially so if it was was a problem on the mac, it wasn't a fatal problem.

We can be pretty flexible with the naming of the files, since Cypress doesn't actually care about the file names as long as the the method files end in '.st' ... so I suppose folks could change the mapping if they liked ... If someone (hint, hint) wanted to add an issue to the FileTree implementation, I could make it easy for folks to change the substitution map ... you'd be departing from the accepted standard, but it would only affect your own repository if you intend on sharing the repo with other folks using the same or different dialects you wouldn't want to use your custom mapping otherwise there would be major confusion (hmmm, the mapping could be on a repository by repository basis)....

@seandenigris
Copy link

My issue with $. replacing $: is that $. is already a concept in the domain of filenames, and overloading it could create confusion (I was confused by file names like Xxx..st, thought it was a bug, and went on a goose chase posting and searching issues).

A slight note in favor of $- replacing $: (if it has to be replaced at all) is that that's what the Pharo slice creator does.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants