[Pharo-project] 'foo' asTime
The kind of think I hate. Time readFrom: aString I will deprecate it. I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague). Stef
Guess what it does.
Not what I expect it to do.
Cheers Philippe
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'. This smacks of working for the computer instead of the other way around. Brent
humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds. Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model". Fernando On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 23, 2010 at 9:07 AM, Fernando olivero <fernando.olivero@usi.ch>wrote:
humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds.
Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model".
maybe where are discussing what we prefer...if nice in words/language or better in OOP. For example, I may (not sure) agree Number understands #seconds. But I may think also that a better OOP would not Number understand #seconds but stead have Duration seconds: 3 But...'3 seconds' is nicer...it is more similar to our language.
Fernando
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I agree that String>>asTime is an accident waiting to happen. It's not that much effort to use the following: Time readFromString: aString But there is a problem with the readFromString: method as well. At the very least, if the string does not represent a valid time, it should throw an error. On 23 Aug 2010, at 09:16, Mariano Martinez Peck wrote:
On Mon, Aug 23, 2010 at 9:07 AM, Fernando olivero <fernando.olivero@usi.ch> wrote: humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds.
Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model".
maybe where are discussing what we prefer...if nice in words/language or better in OOP.
For example, I may (not sure) agree Number understands #seconds. But I may think also that a better OOP would not Number understand #seconds but stead have Duration seconds: 3
But...'3 seconds' is nicer...it is more similar to our language.
Fernando
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 23, 2010, at 9:39 AM, Johan Brichau wrote:
I agree that String>>asTime is an accident waiting to happen. It's not that much effort to use the following: Time readFromString: aString
But there is a problem with the readFromString: method as well. At the very least, if the string does not represent a valid time, it should throw an error.
yes
On 23 Aug 2010, at 09:16, Mariano Martinez Peck wrote:
On Mon, Aug 23, 2010 at 9:07 AM, Fernando olivero <fernando.olivero@usi.ch> wrote: humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds.
Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model".
maybe where are discussing what we prefer...if nice in words/language or better in OOP.
For example, I may (not sure) agree Number understands #seconds. But I may think also that a better OOP would not Number understand #seconds but stead have Duration seconds: 3
But...'3 seconds' is nicer...it is more similar to our language.
Fernando
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/23 Mariano Martinez Peck <marianopeck@gmail.com>
On Mon, Aug 23, 2010 at 9:07 AM, Fernando olivero <fernando.olivero@usi.ch
wrote:
humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds.
Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model".
maybe where are discussing what we prefer...if nice in words/language or better in OOP.
For example, I may (not sure) agree Number understands #seconds. But I may think also that a better OOP would not Number understand #seconds but stead have Duration seconds: 3
But...'3 seconds' is nicer...it is more similar to our language.
What do you think of http://api.rubyonrails.org/classes/ActiveSupport/CoreExtensions/Numeric/Time... ? Indeed I don't like '2010/08/01' asTime, but I like 3 seconds. Laurent
Fernando
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 23, 2010, at 9:40 AM, laurent laffont wrote:
Indeed I don't like '2010/08/01' asTime, but I like 3 seconds.
And I think the reason is the following: '2010/08/01' asTime this is just code... "string, you smalltalk object, please convert yourself into an object of another class that you normally should know too much about". No reason why not to ask the Time class: hey, time, I have a string, can you make a time for me? And it's even nicer... Time knows about time, string about being a string. BUT: 1 second + 3 hours This is different. This is a *domain specific language* for dealing with time. When you read that, you do not think in term of general smalltalk code for coverting between classes. We are (kind of) outside of our language model and the rules we normally follow do not apply. (e.g. there is no hour and second class...). Domain specific languages are powerful, and one can abuse them very easily. (am guilty of having written once some awful DSL where even the *name* of a block parameter had semantic meaning ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
2010/8/23 Marcus Denker <marcus.denker@inria.fr>
On Aug 23, 2010, at 9:40 AM, laurent laffont wrote:
Indeed I don't like '2010/08/01' asTime, but I like 3 seconds.
And I think the reason is the following:
'2010/08/01' asTime
this is just code... "string, you smalltalk object, please convert yourself into an object of another class that you normally should know too much about". No reason why not to ask the Time class: hey, time, I have a string, can you make a time for me? And it's even nicer... Time knows about time, string about being a string.
Yes. So I think I should avoid to show 'http://www.google.com' asUrl in pharocasts...... Laurent
BUT:
1 second + 3 hours
This is different. This is a *domain specific language* for dealing with time. When you read that, you do not think in term of general smalltalk code for coverting between classes. We are (kind of) outside of our language model and the rules we normally follow do not apply. (e.g. there is no hour and second class...).
Domain specific languages are powerful, and one can abuse them very easily. (am guilty of having written once some awful DSL where even the *name* of a block parameter had semantic meaning ;-)
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
yes! I did not say anything the last time because I did not want to break the fun.
2010/8/23 Marcus Denker <marcus.denker@inria.fr>
On Aug 23, 2010, at 9:40 AM, laurent laffont wrote:
Indeed I don't like '2010/08/01' asTime, but I like 3 seconds.
And I think the reason is the following:
'2010/08/01' asTime
this is just code... "string, you smalltalk object, please convert yourself into an object of another class that you normally should know too much about". No reason why not to ask the Time class: hey, time, I have a string, can you make a time for me? And it's even nicer... Time knows about time, string about being a string.
Yes. So I think I should avoid to show 'http://www.google.com' asUrl in pharocasts......
Laurent
BUT:
1 second + 3 hours
This is different. This is a *domain specific language* for dealing with time. When you read that, you do not think in term of general smalltalk code for coverting between classes. We are (kind of) outside of our language model and the rules we normally follow do not apply. (e.g. there is no hour and second class...).
Domain specific languages are powerful, and one can abuse them very easily. (am guilty of having written once some awful DSL where even the *name* of a block parameter had semantic meaning ;-)
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Mon, Aug 23, 2010 at 11:57 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
yes! I did not say anything the last time because I did not want to break the fun.
Don't hesitate to put some "Guru" tips in comments. Because it's really hard to know its own misconceptions :) I don't think it would break the fun (well.... unless you write "stupid idiot bastard don't use String>>#asUrl burn in hell !!!") but bring emulation. Laurent
2010/8/23 Marcus Denker <marcus.denker@inria.fr>
On Aug 23, 2010, at 9:40 AM, laurent laffont wrote:
Indeed I don't like '2010/08/01' asTime, but I like 3 seconds.
And I think the reason is the following:
'2010/08/01' asTime
this is just code... "string, you smalltalk object, please convert
yourself into an object of another class that
you normally should know too much about". No reason why not to ask the Time class: hey, time, I have a string, can you make a time for me? And it's even nicer... Time knows about time, string about being a string.
Yes. So I think I should avoid to show 'http://www.google.com' asUrl in pharocasts......
Laurent
BUT:
1 second + 3 hours
This is different. This is a *domain specific language* for dealing with time. When you read that, you do not think in term of general smalltalk code for coverting between classes. We are (kind of) outside of our language model and the rules we normally follow do not apply. (e.g. there is no hour and second class...).
Domain specific languages are powerful, and one can abuse them very easily. (am guilty of having written once some awful DSL where even the *name* of a block parameter had semantic meaning ;-)
Marcus
-- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Yes!
On Mon, Aug 23, 2010 at 9:07 AM, Fernando olivero <fernando.olivero@usi.ch> wrote: humm...I agree with Kent Beck and Stef, because conceptually a String shouldnt know how to answer #seconds.
Maybe its a matter of having better interactions, smarter text morphs , than introducing this in the "model".
maybe where are discussing what we prefer...if nice in words/language or better in OOP.
For example, I may (not sure) agree Number understands #seconds. But I may think also that a better OOP would not Number understand #seconds but stead have Duration seconds: 3
But...'3 seconds' is nicer...it is more similar to our language.
What do you think of http://api.rubyonrails.org/classes/ActiveSupport/CoreExtensions/Numeric/Time... ?
Indeed I don't like '2010/08/01' asTime, but I like 3 seconds.
Laurent
Fernando
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
3 seconds is indeed better. Right now we are talking about string over extension. Stef On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
As an off topic of 3 seconds... Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev? Chalten is a great Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :) With Chalten you could simply write: December second, 2005. If you want to try them, just evaluate: Gofer new squeaksource: 'Chalten'; package: 'Chalten'; load. Cheers, Mariano. On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
3 seconds is indeed better. Right now we are talking about string over extension.
Stef
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
ok here is my take on it: - I would like to have a mini kernel where date time is just good enough for what the system needs - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos so you see I would prefer that people pick the one they like. Now people can have a different opinion and I would like to hear them :) Stef On Aug 23, 2010, at 11:45 PM, Mariano Abel Coca wrote:
As an off topic of 3 seconds...
Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev?
Chalten is a great Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :)
With Chalten you could simply write: December second, 2005.
If you want to try them, just evaluate:
Gofer new squeaksource: 'Chalten'; package: 'Chalten'; load.
Cheers,
Mariano.
On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 3 seconds is indeed better. Right now we are talking about string over extension.
Stef
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Thinking aloud. I usually don't have to write dates in my code, because they are picked by the user. I think that a well built kernel and nice well integrated UI widgets (maybe I'm going out of the scope :P ) are enough in most of the cases. Anyway, IMHO it's very important to review Time>>fromString: because it's useful for serialization stuff. Like webservices and that kind of things a lot of people have to use. I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854 On Tue, Aug 24, 2010 at 8:24 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
ok here is my take on it:     - I would like to have a mini kernel where date time is just good enough for what the system needs     - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos     so you see I would prefer that people pick the one they like. Now people can have a different opinion and I would like to hear them :)
Stef
On Aug 23, 2010, at 11:45 PM, Mariano Abel Coca wrote:
As an off topic of 3 seconds...
Have you considered to include Hernán Wilkinson and Maximiliano Taborda's packages Aconcagua and Chalten in Pharo Dev?
Chalten is a great  Time framework and much better than the ansi Smalltalk 80's Time class, even with the addition of Duration. And it represents the Minute and Second concepts along with Month, Day, DayOfMonth, MonthOfYear, etc. :)
With Chalten you could simply write: December second, 2005.
If you want to try them, just evaluate:
Gofer new    squeaksource: 'Chalten';    package: 'Chalten';    load.
Cheers,
Mariano.
On Mon, Aug 23, 2010 at 5:45 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: 3 seconds is indeed better. Right now we are talking about string over extension.
Stef
On Aug 23, 2010, at 9:00 AM, Brent Pinkney wrote:
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 Aug 2010, at 13:51, Guillermo Polito wrote:
Thinking aloud. I usually don't have to write dates in my code, because they are picked by the user. I think that a well built kernel and nice well integrated UI widgets (maybe I'm going out of the scope :P ) are enough in most of the cases.
+1 I like the libraries that support to write dates and times in neat Smalltalk ways, but they should not compromise the use of date-times when handling strings coming from the UI front-end. Having a 'xxxx' asString that does not return an error when the timestring is wrong cripples that. You would essentially need to use a separate parser-checker before trying to use the basic conversion libraries for date-times.
Anyway, IMHO it's very important to review Time>>fromString: because it's useful for serialization stuff. Like webservices and that kind of things a lot of people have to use.
I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
+1 Are you already onto it? If not, I can make my hands dirty on this one ;-)
On Tue, Aug 24, 2010 at 9:55 AM, Johan Brichau <johan@inceptive.be> wrote:
On 24 Aug 2010, at 13:51, Guillermo Polito wrote:
Thinking aloud. Â I usually don't have to write dates in my code, because they are picked by the user. I think that a well built kernel and nice well integrated UI widgets (maybe I'm going out of the scope :P ) are enough in most of the cases.
+1 I like the libraries that support to write dates and times in neat Smalltalk ways, but they should not compromise the use of date-times when handling strings coming from the UI front-end. Having a 'xxxx' asString that does not return an error when the timestring is wrong cripples that. You would essentially need to use a separate parser-checker before trying to use the basic conversion libraries for date-times.
Anyway, IMHO it's very important to review Time>>fromString: because it's useful for serialization stuff. Â Like webservices and that kind of things a lot of people have to use.
I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
+1 Are you already onto it? If not, I can make my hands dirty on this one ;-)
All yours I think :P.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24 Aug 2010, at 15:01, Guillermo Polito wrote:
I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
+1 Are you already onto it? If not, I can make my hands dirty on this one ;-)
All yours I think :P.
great :-/ Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me.
I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
+1 Are you already onto it? If not, I can make my hands dirty on this one ;-)
All yours I think :P.
great :-/
Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me.
I thought that readFromString: was raising an error and that guessNumber* was returning zero
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But: 'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error aargh :-( disclaimer: currently testing this in pharo1.1 Johan
In squeak, (Integer readFromString: 'foo') ->Error Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests But that conversation already took place many times... I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ? Nicolas 2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi nicolas If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants] Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible? So I would give a try to get readFrom: clean. Johan please give a try Stef
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&colsp... On Wed, Aug 25, 2010 at 4:32 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that
guessNumber* was returning zero
I thought that too. I even have application code that shows that this
used to return nil in some version of Pharo...
But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
cool now let us see where it breaks and fix. Stef On Aug 25, 2010, at 3:58 PM, Guillermo Polito wrote:
I fixed Integer>>readFrom: yesterday. Its in the inbox http://code.google.com/p/pharo/issues/detail?id=2857&q=String%20Number&colsp...
On Wed, Aug 25, 2010 at 4:32 AM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting. See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format'] One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream Nicolas
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code  (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 25, 2010, at 10:50 PM, Nicolas Cellier wrote:
2010/8/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting.
I integrated the changes of guillermo. But readFrom:ifFail: is a nice API.
See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format']
One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream
Yes. I was thinking about something in the same vein so that we could walk on the stream Now I think that we should get a concrete case to learn from. First raising an error instead of zero is a good behavior and it may break some code. Stef
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, I was so happy to see somebody ringing the "don't return nil; raise an exception" alram that I completely missed the time (and date?) connection. Any #readFrom:* method will be inadequate due to formats. Dolphin tackles thiat with type converters, and I have a minimal set that I fully intend to grow. See http://squeaksource.com/PharoInbox/DolphinCompatibility-ValueAdapters-BillSc... and repeat after me: Caveat Emptor. Beyond that, if the code runs w/o my streams enhancements installed, please let me know - I would consider that a horrible bug. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 25, 2010 5:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime http://code.google.com/p/pharo/issues/detail?id=2859 Stef _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I should look at your code. Just busy and dead tired. Stef On Aug 25, 2010, at 11:51 PM, Schwab,Wilhelm K wrote:
Stef,
I was so happy to see somebody ringing the "don't return nil; raise an exception" alram that I completely missed the time (and date?) connection. Any #readFrom:* method will be inadequate due to formats. Dolphin tackles thiat with type converters, and I have a minimal set that I fully intend to grow. See
http://squeaksource.com/PharoInbox/DolphinCompatibility-ValueAdapters-BillSc...
and repeat after me: Caveat Emptor. Beyond that, if the code runs w/o my streams enhancements installed, please let me know - I would consider that a horrible bug.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 25, 2010 5:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime
http://code.google.com/p/pharo/issues/detail?id=2859
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stef, It took me a while to check and release it (browser environments+Shout to the rescue), so you have some time yet :) Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Thursday, August 26, 2010 3:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime I should look at your code. Just busy and dead tired. Stef On Aug 25, 2010, at 11:51 PM, Schwab,Wilhelm K wrote:
Stef,
I was so happy to see somebody ringing the "don't return nil; raise an exception" alram that I completely missed the time (and date?) connection. Any #readFrom:* method will be inadequate due to formats. Dolphin tackles thiat with type converters, and I have a minimal set that I fully intend to grow. See
http://squeaksource.com/PharoInbox/DolphinCompatibility-ValueAdapters-BillSc...
and repeat after me: Caveat Emptor. Beyond that, if the code runs w/o my streams enhancements installed, please let me know - I would consider that a horrible bug.
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Wednesday, August 25, 2010 5:00 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime
http://code.google.com/p/pharo/issues/detail?id=2859
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would like to be *able* to use a read method to pull from a stream with other data in it. Whether it needs to be at the end when that is over is open for debate, perhaps left to the caller?? It is an important question. Off the top of my head, it seems that Dolphin somewhat dodges it for dates and times by taking strings. I can check on whether they raise errors if there is "stuff left over." Again, I am fully supportive of raising errors by default. They help to fix a lot more trouble than they cause. ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Wednesday, August 25, 2010 4:50 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime 2010/8/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting. See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format'] One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream Nicolas
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that guessNumber* was returning zero
I thought that too. I even have application code that shows that this used to return nil in some version of Pharo... But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D. On Wed, Aug 25, 2010 at 7:55 PM, Schwab,Wilhelm K <bschwab@anest.ufl.edu>wrote:
I would like to be *able* to use a read method to pull from a stream with other data in it. Whether it needs to be at the end when that is over is open for debate, perhaps left to the caller?? It is an important question. Off the top of my head, it seems that Dolphin somewhat dodges it for dates and times by taking strings. I can check on whether they raise errors if there is "stuff left over."
Again, I am fully supportive of raising errors by default. They help to fix a lot more trouble than they cause.
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [ pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Nicolas Cellier [nicolas.cellier.aka.nice@gmail.com] Sent: Wednesday, August 25, 2010 4:50 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] 'foo' asTime
2010/8/25 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi nicolas
If I understand you correctly we are in sync. Yes readFrom: should read or fails raising an Error and we should use Integer readFrom: 'foo' ifFail: [the default value that the client knows that he wants]
Now we integrated your number parsers so this is strange that the behavior is not like you mention did you make them backwards compatible?
So I would give a try to get readFrom: clean. Johan please give a try
Stef
Yes, all the infrastructure is there, just change the top message to be awkward-uncompatible ;) like Guillermo is suggesting.
See also my other suggestion: implement #readFrom:ifFail: in every class instead of #readFrom: and let readFrom default implementation to just be ^self readFrom: aStream ifFail: [self error: 'invalid format']
One question I'm not sure about is whether we should distinguish 2 API's: - one for reading a single object and bark on extra-characters - IMO, this would be the correct Behaviour of #readFromString: - one for reading an object in a longer sequence of objects (just keep the stream positionned after last character read) - this would be readFrom: aStream
Nicolas
In squeak, (Integer readFromString: 'foo') ->Error
Use: - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, - (Integer readFrom: 'foo' ifFail: []), to get nil
Though it is possible, I dislike anwsering nil, because it would mean a bunch of #readFrom: send should be protected by #ifNil: Blocks... 1) That's nonsense, readFrom:ifFail: already does the work. 2) you cripple the code with Error conditions and end up with unreadable C-looking like code (3 lines of Error condition crap for 1 line of underlying algorithm at every function call) 3) Exception handling can avoid long chains of ifFail: / ifNil: tests
But that conversation already took place many times...
I'd like the readFrom:ifFail: form to be generalized to other objects, with default behaviour raising an Error. What do you think ?
Nicolas
2010/8/24 Johan Brichau <johan@inceptive.be>:
On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote:
I thought that readFromString: was raising an error and that
guessNumber* was returning zero
I thought that too. I even have application code that shows that this
used to return nil in some version of Pharo...
But:
'foo' asInteger = nil Integer readFromString: 'foo' = 0 'foo' asNumber -> Error
aargh :-(
disclaimer: currently testing this in pharo1.1
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 26 Aug 2010, at 04:47, Guillermo Polito wrote:
And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D.
Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-) Johan
johan thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now. Stef On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote:
On 26 Aug 2010, at 04:47, Guillermo Polito wrote:
And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D.
Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-)
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
err, yes it actually still is this one: http://code.google.com/p/pharo/issues/detail?id=2854 :-) On 27 Aug 2010, at 10:16, Stéphane Ducasse wrote:
johan
thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now.
Stef
On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote:
On 26 Aug 2010, at 04:47, Guillermo Polito wrote:
And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D.
Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-)
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ok normally this is integrated now. On Aug 27, 2010, at 12:11 PM, Johan Brichau wrote:
err, yes it actually still is this one: http://code.google.com/p/pharo/issues/detail?id=2854 :-)
On 27 Aug 2010, at 10:16, Stéphane Ducasse wrote:
johan
thanks Now get the reflex to create an issue else we get flooded of information. I will integrate them now.
Stef
On Aug 26, 2010, at 2:34 PM, Johan Brichau wrote:
On 26 Aug 2010, at 04:47, Guillermo Polito wrote:
And now, because of fixing Integer>>readFrom:, 'foo' asTime throws an exception and we all are a bit happier :D.
Indeed. thanks. And just to make sure that we keep being happy, I added some unit tests to verify that in the KernelTests package ;-)
Johan _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
*readFrom: aStringOrStream base: base "Answer an instance of one of the concrete subclasses if Integer. Initial minus sign accepted, and bases > 10 use letters A-Z. Imbedded radix specifiers not allowed; use Number class readFrom: for that. Raise an Error if there are no digits. If stringOrStream dos not start with a valid number description, answer 0 for backward compatibility. This is not clever and should better be changed." ^(SqNumberParser on: aStringOrStream) failBlock: [^0]; nextIntegerBase: base * Mmm, I hate backwards compatibility ¬¬. Maybe we can... 1) create a new Integer>>fromStringOrAnotherNameThatPleaseUs: which fails when it has to :) 2) deprecate the old one? So we can change the dependants gradually. On Tue, Aug 24, 2010 at 10:16 AM, Johan Brichau <johan@inceptive.be> wrote:
On 24 Aug 2010, at 15:01, Guillermo Polito wrote:
I opened a ticket http://code.google.com/p/pharo/issues/detail?id=2854
+1 Are you already onto it? If not, I can make my hands dirty on this one
;-)
All yours I think :P.
great :-/
Anyway, the problem goes down to Integer>>readFromString: which returns 0 if the string does not represent a number. The comment says something about backwards compatibility, so we'll have to approach the issue with care but having 0 as the error value is flabbergasting to me. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/8/24 Stéphane Ducasse <stephane.ducasse@inria.fr>:
ok here is my take on it:     - I would like to have a mini kernel where date time is just good enough for what the system needs     - then people load the framework they want and yes I love aconcagua and chalten but there is also chronos     so you see I would prefer that people pick the one they like. Now people can have a different opinion and I would like to hear them :)
I have a different opinion :) - Time is presupposed in every computer system I've seen, I would like to have or see a system without Time. Such is the influence of Kant today. - If one could remove the time and experiment teaching the system like an idealist would do, this could open doors to whole new things. - Bottom line, I would like to replace time instead of having just one mini kernel Does time exists if nothing is changed? ;) Hernán
+1 One of our developers recently complained of #asInteger being removed from ByteArray for instance... Regards, Gary ----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
what is #[12 35] asInteger? Stef On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled. Now everybody can create his own personal package with the extensions they like. Stef On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
He was porting his stuff from Squeak 3.9 3107 apparently. c.f. #(12 35) asByteArray asInteger asByteArray Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) ) Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too. Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Odd, my 3.9 works. Method ByteArray>>asInteger by "len 10/15/2002 18:45" Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:33 AM Subject: Re: [Pharo-project] 'foo' asTime On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too. Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote:
Odd, my 3.9 works.
Method ByteArray>>asInteger by "len 10/15/2002 18:45"
Regards, Gary
Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:33 AM Subject: Re: [Pharo-project] 'foo' asTime
On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too.
Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Indeed it would make sense. On Aug 23, 2010, at 2:03 PM, Henrik Johansen wrote:
On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote:
Odd, my 3.9 works.
Method ByteArray>>asInteger by "len 10/15/2002 18:45"
Regards, Gary
Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it?
Cheers, Henry
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:33 AM Subject: Re: [Pharo-project] 'foo' asTime
On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too.
Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Ar, that'd be it... Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 1:03 PM Subject: Re: [Pharo-project] 'foo' asTime On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote:
Odd, my 3.9 works.
Method ByteArray>>asInteger by "len 10/15/2002 18:45"
Regards, Gary
Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:33 AM Subject: Re: [Pharo-project] 'foo' asTime
On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too.
Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Though not an extension in the Crypto package... Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 2:20 PM Subject: Re: [Pharo-project] 'foo' asTime Ar, that'd be it... Regards, Gary ----- Original Message ----- From: "Henrik Johansen" <henrik.s.johansen@veloxit.no> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 1:03 PM Subject: Re: [Pharo-project] 'foo' asTime On Aug 23, 2010, at 1:28 28PM, Gary Chambers wrote:
Odd, my 3.9 works.
Method ByteArray>>asInteger by "len 10/15/2002 18:45"
Regards, Gary
Integer >> asByteArray is in a 1.0 image, introduced when MD5 was put into core. Maybe you have the Cryptography package in your 3.9 image, and that included it? Cheers, Henry
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:33 AM Subject: Re: [Pharo-project] 'foo' asTime
On Aug 23, 2010, at 12:21 PM, Gary Chambers wrote:
He was porting his stuff from Squeak 3.9
3107 apparently.
c.f. #(12 35) asByteArray asInteger asByteArray
This is what I tried #(12 35) asByteArray asInteger on my old 3.9 7067 final image and it barks. Then a nice explicit loops should make it too.
Stef
Unfortunately heavily used when doing low-level stuff with external devices socket data etc. (let us not get into endianess either though ;-) )
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 11:01 AM Subject: Re: [Pharo-project] 'foo' asTime
#[12 35] asInteger is not in 1.0, 1.1, and 1.2 It does not work in squeak trunk either did not work in 3.9 either. So I'm puzzled.
Now everybody can create his own personal package with the extensions they like.
Stef
On Aug 23, 2010, at 11:52 AM, Gary Chambers wrote:
+1
One of our developers recently complained of #asInteger being removed from ByteArray for instance...
Regards, Gary
----- Original Message ----- From: "Brent Pinkney" <brent@zamail.co.za> To: <Pharo-project@lists.gforge.inria.fr> Sent: Monday, August 23, 2010 8:00 AM Subject: Re: [Pharo-project] 'foo' asTime
I would really like to have the approach proposed by K. Beck on conversion methods. Conversion methods for API compatible objects. Of course it will lead to less compact program (URL readFrom: 'http://' instead of 'http://' url) but avoids a lot of code in String (of course class extensions limit the plague).
Hi, please reconsider this. There is just no way (Duration seconds: 3) is better than '3 seconds'.
This smacks of working for the computer instead of the other way around.
Brent
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (15)
-
Brent Pinkney -
Fernando olivero -
Gary Chambers -
Guillermo Polito -
Henrik Johansen -
Hernán Morales Durand -
Johan Brichau -
laurent laffont -
Marcus Denker -
Mariano Abel Coca -
Mariano Martinez Peck -
Nicolas Cellier -
Philippe Marschall -
Schwab,Wilhelm K -
Stéphane Ducasse