I am curious is there anything in Smalltalk as a language (not the tools/ enviroment / ide) that imposes case sensitivity ? -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691240.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

So that means the naming conventions used my pharo are imposed by the enviroment itself like starting with lowercase for methods and highercase for classes. Very interesting , another reason for me to like smalltalk even more :) -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691269.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

These kind of features and flexibility should be more promoted to coders. Its these things that make smalltalk so special , yet people like me who are still very fresh to it deal with it like its another python or ruby. -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691334.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

On Jun 3, 2013, at 1:13 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

I thought so. Attached hack removes it.

Of course a complete rewrite of the class builder is ready for integration… https://ci.inria.fr/pharo-contribution/job/Slot/ So the question is if it makes sense to add this one? Marcus

Jan

On 31/05/13 14:47, Marcus Denker wrote:

...

On May 31, 2013, at 1:32 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

...

Hi

is there any reason why class builder does not allow lowercase classnames? Underscore is allowed, though.

In the past people started too add check to make sure that we only use the naming that people are supposed to use. The place these checks where placed was the class builder. Over time it has shown that this is not good: it has do be done on a higher level.

(we already removed certain checks, e.g. about variable capitalization).

We should at some point introduce something that does these kinds of checks for the tools, but allows one to just do anything when needed at the lower level…

Marcus

<ClassBuilder-validateClassName.st>

On Jun 6, 2013, at 9:29 AM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

On 03/06/13 12:18, Marcus Denker wrote:

...

On Jun 3, 2013, at 1:13 PM, Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

...

I thought so. Attached hack removes it.

Of course a complete rewrite of the class builder is ready for integration…

https://ci.inria.fr/pharo-contribution/job/Slot/

So the question is if it makes sense to add this one?

Hm...I'm not sure what you mean.

I mean that we should not change ClassBuilder now if it is replaced next week. (man power is limited).

Let put it this way? Any chance 2.0 will allow lowercase class names?

The problem with changing 2.0 is that all change always has side-effect impacting others… often in very non-expected ways. So I am a bit skeptical to change 2.0, especially anything in the dark places like the class builder. If it is a change that is for the good of all users, is makes sense to invest time and effort. But changing the class builder in 2.0 just for an experiment of one person? I would tend to argue to not do it. The current development version is another story. There we can break things, have time to stabilize. Marcus

When I was coding with python I used underscore instead of camel case. MorphWindow -> morph_window and I also like common lisp approach MorphWindow -> morph-window I always found camel case very weird , since back in 1996 that i saw it used in C++. And even though I have grown up reading it , I am still find it difficult especially with lenghty code. Of course what happens in pharo should be a democratic decision, but I dont think allowing for freedom to choose is a bad thing. Thats how python works, and most programming languages. Only pharo / squeak than I know of foces usage of Camel case, and capitalisation of first letter in classes . Cant say i find it a good thing. -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691925.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

A pitty , I think python has the same limitations with whitespace. Its kinda weird because python forces indentation as part of the syntax ( a reason why some people hate python) and yet it finds it perfectly fine to do a 3-4 which to me is pretty much a very obvious readability problem (at least something my math teacher would have complained about ;) ). But none the less, I am ok with camel case , and I am certainly ok with how pharo forces naming conventions. I find documentation a lot bigger deal for a coder than how he names methods and classes. Also it should not be so hard to implement a parser (PettitParser ? ) for adding those features in , without changing pharo or smalltalk syntax , as a third party library. Afterall thats the purpose of OOP , to extend and not to modify code :) The one thing I was thinking for implementing for my project Ephestos, was a more english language version of smalltalk , where a name of a class can have even whitepaces inside it. I have to confess its a rather low priority idea for now, cause I am already over my head with opengl and nativeboost but it would be a fun area to explore. I was thinking replacing lisp parentheses in some way with graphical elements that dicate where the name starts and ends and where the parameters also start and end. A bit like Scratch but much more transparent without kicking out standard smalltalk syntax. For example ((3d cube morph ) (draw on screen ( x : 500 y: 400 ))) . where parentheses represent graphical elements (user wont type parentheses but rather use key shortcuts, maybe tabs ) in the text editor which could be made transparent so the code reads (and hovering the mouse on top of class and methods names could make visible the graphical elements again) 3d cube morph draw on screen x :500 y: 400 . With autocompletion to cut down typing and even autofill in the class name just by using the method name ( if same methods exist in other classes a drop down menu autocompletition style will allow him to choose the right class). The above of course will still be commited as smalltalk code 3dCubeMorph drawOnScreen x: 500 y:400 so it will be more like an illusion for the coder, for pharo will be regular smalltalk code. Of course that has the advantage of existing smalltalk code being displayed with this syntax , again with zero changes to source code commited. Its an idea I would like to try at some point, no promises when :D -- View this message in context: http://forum.world.st/Pharo-dev-Lowecase-class-names-tp4690963p4691944.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.