author initials / truncation and round off

Hello,
I come from VisualWorks world and am new to squeak environment.
I spent a lot of time searching where i could change author initials that were
asked to me the first time i fed the browser, untill i found the item in Help
menu.
Would not the changes menu just above be a more logical place ?
By the way, is this the right place for this kind of minor suggestion ?

I have some more general questions that will be illustrated using truncation
and round off example.
I noticed that the #roundTo: was implemented only in Number Collection and
Duration, while #truncateTo: was also in Point and Rectangle.
#roundUpTo: is only in Number (though ceiling is defined in Number Collection
and Duration).
#roundDownTo: is nowhere at all, probably because no one ever used it.
Complex has no mean to rounding.
Who makes decisions about where to implement such general purpose messages ?
Should Squeak search a better uniformity of library at expense of a bigger
image or reduce the kernel only to messages that are used ? (but then lot of
people would implement the same extension, me first).

If the response is uniformity, i can provide code for completing that as soon
as i find how to publish... Are you interested ?

I have already published a SYSEXT-rounding in VW Cincom public repository,
because it will be a prereq of some other packages.
In VW, I had chosen the names #ceilingTo: and #floorTo:, because i found that
it had a certain symmetry with the way other messages were formed : truncated
-> truncateTo:, rounded -> roundTo:, ceiling -> ...
But maybe ceilingTo: is bad english compared to roundUpTo: , a french
shouldn't decide that...
My question is who decides ? Shouldn't be an agreement found with other
dialect makers ? is it ANSI stuff ? Or maybe no use to discuss so long each
and every message, one decides and the others follow ? An intermediate
between central decision at dialect level and co-operation at language level
might be the right answer.

My user point of view is that Squeak VW Dolphin VisualAge Smalltalk/X etc...
should either discuss more about the kernel libraries or borrow more from
each other and do some sort of cross dialect refactoring...
Because it will ease porting from a Smalltalk dialect to another.
I would like to develop freeware, but i feel that maintaining several dialect
dependent versions of a general purpose library is a bad situation...
Smalltalk has not been invented to fall back to the C code #ifdef _MSCVER
nightmare, has it ?
As a commercially paying Smalltalk user in a previous job, I can tell you that
it has also been a brake on using Smalltalk, because it is neither a good
situation being bound to a vendor specific environment and library. And the
cost of porting is high. If i want to reduce the cost by porting some base
library in another vendor image, there will certainly be some licensing
problems, though i am pretty sure every body do it...
My advice to commercial Smalltalks: forget about copywriting and patenting
libraries, you are killing yourself. Maybe better concentrate on VM
optimizations, services, or i don't know, you'll have to invent... And please
do favour inter dialect library exchange, you all are to win of it. Don't be
on the defensive, behind a Maginot line, you're dead, trust a french.
I am sure Squeak team agree since non commercial. But maybe i am out of the
scope of this list again ?

On 5 févr. 06, at 02:00, nicolas cellier wrote:

> Hello,
> I come from VisualWorks world and am new to squeak environment.
> I spent a lot of time searching where i could change author  
> initials that were
> asked to me the first time i fed the browser, untill i found the  
> item in Help
> menu.
> Would not the changes menu just above be a more logical place ?

It would, but nobody dared/cared to refactor the menus....and clean  
the mess

> By the way, is this the right place for this kind of minor  
> suggestion ?

Sure

Nobody, now. But in the past the SqueakC team was "taking care of that"
This is why squeak is lacking some general.


> Should Squeak search a better uniformity of library at expense of a  
> bigger
> image or reduce the kernel only to messages that are used ? (but  
> then lot of
> people would implement the same extension, me first).

My impression is that having
        - coherent and uniform protocols is important
        - having a small and coherent kernel is possible but it required  
time and effort.

> If the response is uniformity, i can provide code for completing  
> that as soon
> as i find how to publish... Are you interested ?

Sure.
Please, and if you would have tests covering that this would even be  
better.
http://www.iam.unibe.ch/~ducasse/Programmez/OnTheWeb/Art8-SUnit.pdf

This central entity does not exist.
So the best is to try to be close or following what exist in other  
dialects
and document them (with tests).

> My user point of view is that Squeak VW Dolphin VisualAge Smalltalk/
> X etc...
> should either discuss more about the kernel libraries or borrow  
> more from
> each other and do some sort of cross dialect refactoring...

This is happening but difficult to put in practice.

> Because it will ease porting from a Smalltalk dialect to another.
> I would like to develop freeware, but i feel that maintaining  
> several dialect
> dependent versions of a general purpose library is a bad situation...
> Smalltalk has not been invented to fall back to the C code #ifdef  
> _MSCVER
> nightmare, has it ?

We know. But this is a reality.

> As a commercially paying Smalltalk user in a previous job, I can  
> tell you that
> it has also been a brake on using Smalltalk, because it is neither  
> a good
> situation being bound to a vendor specific environment and library.

sad but true. But we cannot do too much except paying attention to be
as compatible as possible and have good way of ensuring that the  
semantics
is clear and easy to maintain.

:)
May be you should send that in the VW mailing-list :)

> I am sure Squeak team agree since non commercial. But maybe i am  
> out of the
> scope of this list again ?

Non :)
I suggest you to post one topic per email if you want that people  
reply to all of them :)


Stef