Some tips to port packages to Cuis

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Some tips to port packages to Cuis

garduino
Hi Guys:

Only now happened to me that could be interesting to compile in a document some differences between Cuis and Pharo/Squeak to take in account when porting code.


HTH.

--
============================================
Germán S. Arduino  <gsa @ arsol.net>   Twitter: garduino
Arduino Software  http://www.arduinosoftware.com
PasswordsPro  http://www.passwordspro.com
greensecure.blogspot.com germanarduino.blogspot.com
============================================

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Some tips to port packages to Cuis

Juan Vuletich-4
Hi Germán,

Germán Arduino wrote:

> Hi Guys:
>
> Only now happened to me that could be interesting to compile in a
> document some differences between Cuis and Pharo/Squeak to take in
> account when porting code.
>
> I started here: https://gist.github.com/4323555
>
> HTH.
>
> --
> ============================================
> Germán S. Arduino  <gsa @ arsol.net <http://arsol.net>>   Twitter:
> garduino
> Arduino Software  http://www.arduinosoftware.com
> PasswordsPro  http://www.passwordspro.com
> greensecure.blogspot.com <http://greensecure.blogspot.com>
> germanarduino.blogspot.com <http://germanarduino.blogspot.com>
> ============================================

Good list. Let's review them. Cuis is open for enhancements! Please
don't take Cuis like carved on stone. Let's enhance it together!

1)
String >>indexOfSubCollection: sub startingAt: start ifAbsent:
exceptionBlock
instead of: String >> indexOfSubCollection: sub

I'll add this method today. I see no reason for not having it.

2)
String crCharacter
instead of: String cr

String lfCharacter
instead of: String lf

String crlfString
instead of: String crlf

 The reason for all these was to enable and test the conversion to LF
convention for Cuis. I wanted to know which senders of #cr and such
wanted a Character and which wanted a String. Naming the methods the
same is "false plymorphism". But the conversion to LF is already done,
and this affects compatibility for no good reason. There are 2
possibilities here: a) add #cr, #lf, #cflf, etc as compatibility
methods, or b) remove #crCharacter and such, changing senders back.
Opinions?

3)
Smalltalk at:
instead of: Smalltalk globals at:

This one is easy. In Cuis, #globals should answer self. A similar trick
for SmalltalkImage current and such. All these can simply answer Smalltalk.

Everybody, please tell your opinion about these stuff and the options.
And keep posting such gracious compatibility issues so we can address them.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Some tips to port packages to Cuis

garduino
Hi Juan:

2012/12/18 Juan Vuletich <[hidden email]>
Hi Germán,

Germán Arduino wrote:
Hi Guys:

Only now happened to me that could be interesting to compile in a document some differences between Cuis and Pharo/Squeak to take in account when porting code.

I started here: https://gist.github.com/4323555

HTH.

--
============================================
Germán S. Arduino  <gsa @ arsol.net <http://arsol.net>>   Twitter: garduinogreensecure.blogspot.com <http://greensecure.blogspot.com> germanarduino.blogspot.com <http://germanarduino.blogspot.com>
============================================

Good list. Let's review them. Cuis is open for enhancements! Please don't take Cuis like carved on stone. Let's enhance it together!


Yes, this is my idea, as I don't know what additions you want to add or not I think that this list is a good reference.

Also think is a good starting point to people learning Cuis or trying to port packages.


 
1)
String >>indexOfSubCollection: sub startingAt: start ifAbsent: exceptionBlock
instead of: String >> indexOfSubCollection: sub

I'll add this method today. I see no reason for not having it.



ok, I will fix the list.
 
2)
String crCharacter
instead of: String cr

String lfCharacter
instead of: String lf

String crlfString
instead of: String crlf

The reason for all these was to enable and test the conversion to LF convention for Cuis. I wanted to know which senders of #cr and such wanted a Character and which wanted a String. Naming the methods the same is "false plymorphism". But the conversion to LF is already done, and this affects compatibility for no good reason. There are 2 possibilities here: a) add #cr, #lf, #cflf, etc as compatibility methods, or b) remove #crCharacter and such, changing senders back. Opinions?


In the packages I ported/porting exist a lot of this stuff....so I think that have the same that in other distros would be useful. I  can't predict if removing the current #crCharacter & friends will affect other already "cuised" packages (Style Text, etc).

I think that having all of them have more advantages than disadvantages.

 
3)
Smalltalk at:
instead of: Smalltalk globals at:

This one is easy. In Cuis, #globals should answer self. A similar trick for SmalltalkImage current and such. All these can simply answer Smalltalk.


But this is not the case now, right?

For example I think that SmalltalkImage don't exist currently in Cuis....or I'm very wrong?

 
Everybody, please tell your opinion about these stuff and the options. And keep posting such gracious compatibility issues so we can address them.


I think that this is an important point, to have all the possible compatibility that don't affect your sense of clean design of Cuis.

 
Cheers,
Juan Vuletich



Cheers.
Germán.

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org