Remove classFromSymbol: or classNamed: ? about cormas HOT 15 CLOSED

this is because we renamed the method
classFromSymbol: was the old name (which is still used in some old code)
and classNamed: is the new name (it happens that we didn't use the new name yet )

we have to keep both, because the old name might be used in old cormas mdoel and the new name is the one we want end-suers to adopt

from cormas.

actually in cormas/VW, methods with an old name are put in a protocol (do we have protoocls in pharo?) called 'deprecated'
and methods which we want end-users to find easily are put in a protocol which name starts either by '*' or by '+' (like 'public')

from cormas.

Why we want new end-users to adopt classNamed: instead of classFromSymbol: ?

from cormas.

we (pb, clp, nb) found the syntax was more explicit

from cormas.

Yes there is protocols in Pharo like VW. But this is not a good idea to rely on protocols names (i.e String). There is a deprecated API in Pharo. Every time you want to inform end-users about a change in the API, you can use this API.

We can rewrite classFromSymbol: like:

classFromSymbol: aSymbol
self deprecated: 'Use classNamed: instead of classFromSymbol:'.
^self class classFromSymbol: aSymbol

So the end-users, will have a debugger the next time they use this method and they can proceed if they don't to change right now or they have to change the method to use _classNamed:_.

We have also to changed all the _classFromSymbol:_ use in Cormas-core to _classNamed:_.

I will take care of this change.

from cormas.

There is also a lot of methods duplicated at the instance side and class side ... too much duplication of code. We have to define the method once in instance side of class side.
This is the case for classNamed: and classFromSymbol: defined in CormasEntity instance and class side !

I'm not even sure that we need the classNamed: method.
In Pharo we can write : aName class if aName is a Symbol.

from cormas.

u mean we can write
#CormasEntity class
or
#Farmer class

if this the case, the problem is solved!

2015-05-29 11:51 GMT+02:00 Serge Stinckwich [email protected]:

There is also a lot of methods duplicated at the instance side and class
side ... too much duplication of code. We have to define the method once in
instance side of class side.
This is the case for classNamed: and classFromSymbol: defined in
CormasEntity instance and class side !

I'm not even sure that we need the classNamed: method.
In Pharo we can write : aName class if aName is a Symbol.

—
Reply to this email directly or view it on GitHub
#18 (comment).

Nicolas Becu
Chercheur au CNRS
Littoral Environnement et Sociétés (LIENSs) - UMR 7266
Bâtiment ILE
2, rue Olympe de Gouges
17 000 La Rochelle
Tel : 05 16 49 67 94

from cormas.

Yes !

from cormas.

cool

we should check if it is not too much resource consuming
because we do use it a lot (sometimes more than 100 times in one step of
simulation)

2015-05-29 12:01 GMT+02:00 Serge Stinckwich [email protected]:

Yes !

—
Reply to this email directly or view it on GitHub
#18 (comment).

Nicolas Becu
Chercheur au CNRS
Littoral Environnement et Sociétés (LIENSs) - UMR 7266
Bâtiment ILE
2, rue Olympe de Gouges
17 000 La Rochelle
Tel : 05 16 49 67 94

from cormas.

Ok to be done:

• add to manage deprecated code from End-Users:

classFromSymbol: aSymbol
    self deprecated: 'Use class method on Symbol instead of classFromSymbol:'.
    ^ aSymbol class

• replace all code with CormasModel classNamed:xas aSymbol class

from cormas.

I prefer not to take care to performance issues at the moment.
First do it right, after that optimize later if necessary.

from cormas.

ok,
one last question: in vw #Farmer class retuns ByteSymbol
how can u obtain the same answer in pharo ? ('cause u
explained it would return teh Farmer class if it exists )

2015-05-29 12:05 GMT+02:00 Serge Stinckwich [email protected]:

I prefer not to take care to performance issues at the moment.
First do it right, after that optimize later if necessary.

—
Reply to this email directly or view it on GitHub
#18 (comment).

Nicolas Becu
Chercheur au CNRS
Littoral Environnement et Sociétés (LIENSs) - UMR 7266
Bâtiment ILE
2, rue Olympe de Gouges
17 000 La Rochelle
Tel : 05 16 49 67 94

from cormas.

Ask the Finder ;-)

from cormas.

@nbecu I commit the following package. Can you have a look and you can close this issue if everything is ok.

Name: Cormas-Core-SergeStinckwich.104
Author: SergeStinckwich
Time: 29 May 2015, 3:20:27.267606 pm
UUID: af40d280-54b4-4387-af52-f9a7f7f6cb33
Ancestors: Cormas-Core-nbecu.103

- Remove classNamed: implementor never used
- Remove all classFromSymbol: senders and use class method
- Keep all classFromSymbol: implementors and use the deprecated API in order to manage end-users models using the old CORMAS API.

from cormas.

seems all good to me
i looked at all the changes, then loaded and checked that I could pass the Conway new initSimulation.
everything good.

from cormas.