Date classes
Locked
123
123
 
|
> About the code you tried: I may sound repetitive, but everything is explained in the paper. Because of the metaphor we used to create de model (points in a line, the time-line) the messages #next:, #distanceTo:, etc. are better. > You have to do: "GregorianDate today next" or Maybe... or maybe it should be aMeasureOfTime... I think that sounds better. > 4) GregorianYear current + 1 year --> Same as 1) but using a measure I don't understand what you mean... And there is still the question where year comes from I did not see that question, but the answer is No. The variable "year" is global. The same as month, day, January, February, Monday, etc. Maybe you will not like it, but I think that the time domain is so important in writing software as the arithmetic domain, so if numbers are global (1, 2, 3, etc) why not the time objects? They are well know entities of the real life.... Bye, Hernan. Cheers |
|
|
In reply to this post by keith1y
> "But if it is not documented it may as well not exist" - so
> the features you mention that are so great actually for real > purposes (apart from personal hacking) do not exist! Not true. They've been doing lots of stuff lately to improve performance. We all benefit from that whether they document it or not. > When you are working in a professional coding environment, > anything without documentation falls below the radar. > Management cant keep looking at source code to see if a > needed feature has arrived. > > best regards > > Keith I don't see a professional coding environment, I see 3 or 4 guys contributing their spare time writing one of the most kick ass web frameworks ever made. I see check in comments on every commit saying what they did. If there's a lack of comments in the code and on the classes, I don't blame them, I blame us, for not jumping in and helping them out. Would more comments be nice, sure, but lets not make the only guys doing the work feel bad about it. Ramon Leon http://onsmalltalk.com |
|
|
> I don't see a professional coding environment, I see 3 or 4 guys > contributing their spare time writing one of the most kick ass web > frameworks ever made. I see check in comments on every commit saying what > they did. If there's a lack of comments in the code and on the classes, I > don't blame them, I blame us, for not jumping in and helping them out. > Would more comments be nice, sure, but lets not make the only guys doing the > work feel bad about it. > > Kick ass web frameworks for whom, the elite? the premadonnas? What happened to smalltalk being an environment that is so easy a child could do it, making things accessible as part of the culture? I am not trying to make anyone feel bad, it is a cultural thing I was trying to highlight. We have no problem promoting a Testing/Test First culture, why not promote the documentation aspect? If you look in the seaside archives I said it back towards Seaside version 1.0 and 1.1 back in the days before seaside had any credibility. If seaside had had some documentation back then perhaps there would not even be a rails today. Regrettably nothing much has changed, until recently. (i.e. Lukas knows better :-) ) Zope had a book, and as a result zope runs the intranet at my previous company. The actual under the hood code in zope was horrendous, but it has/had a book. PHP has a book, and what a book it is, I saw a printout of the manual once, the sheer size of it scared me. But it has a book, and the market share speaks for itself. Sure documentation is not the only factor but it is a factor. Keith |
|
|
> Kick ass web frameworks for whom, the elite? the premadonnas?
Sadly, right now, those who are willing to put forth the effort to learn it. I'm not saying that's not a problem, only that it's a community problem, not necessarily the core developers problem. > What happened to smalltalk being an environment that is so > easy a child could do it, making things accessible as part of > the culture? I don't think it ever was that, despite its attempts to be. > I am not trying to make anyone feel bad, it is a cultural > thing I was trying to highlight. We have no problem promoting > a Testing/Test First culture, why not promote the > documentation aspect? > > If you look in the seaside archives I said it back towards > Seaside version 1.0 and 1.1 back in the days before seaside > had any credibility. > If seaside had had some documentation back then perhaps there > would not even be a rails today. Regrettably nothing much has > changed, until recently. (i.e. Lukas knows better :-) ) > > Zope had a book, and as a result zope runs the intranet at my > previous company. The actual under the hood code in zope was > horrendous, but it has/had a book. > > PHP has a book, and what a book it is, I saw a printout of > the manual once, the sheer size of it scared me. But it has a > book, and the market share speaks for itself. Sure > documentation is not the only factor but it is a factor. > > Keith I don't disagree, a book would be great. More than anything, Seaside needs documentation, marketing, and a larger community to enable those things, but we don't need to piss of the only people actually doing any work. Philippe's comments seemed to indicate he was rather annoyed. I was just reminding him that we appreciate the effort they put forth, despite any bitching they may feel coming their way. Ramon Leon http://onsmalltalk.com |
|
|
In reply to this post by hernan.wilkinson
2007/4/17, Hernan Wilkinson <[hidden email]>:
> > > > About the code you tried: > > > 1) GregorianDay today + 1 day -> It will not work becuase a date is not > > > polymorphic with numbers. > > > > Why? This works fine with Chronos. I find it quite handy to compute > > the difference between two points in time by sending #-. Or being able > > to add a duration to a timepoint by sending #+. Yeah the type > > signatures are different than for standard arithmetic but still. > > I may sound repetitive, but everything is explained in the paper. > Because of the metaphor we used to create de model (points in a line, the > time-line) the messages #next:, #distanceTo:, etc. are better. > > > > You have to do: "GregorianDate today next" or > > > "GregorianDate today next: 1 * day" Remember the *, that allows you to > > > create measures easily > > > > > > 2) GregorianDateTime now + 1 day ---> Same as 1) > > > > > > 3) GregorianDay today next: 5 --> It will not work because 5 is not a > > > measure of time, it is just a number. Try > > > "GregorianDay today next: 5 * day" 5 * day is a measure of time > > > > Maybe then the suggested type should be aMeasure and not aNumberOfDays > > Maybe... or maybe it should be aMeasureOfTime... I think that sounds better. > > > > 4) GregorianYear current + 1 year --> Same as 1) but using a measure > > > expressed in year, for example "2 * year" > > > 5) 5 months --> Measure are created in many ways. We decided not to > clutter > > > the number protocol with each unit you could have... because measures > are > > > arithmetic representations of a number times its unit, the right way to > > > create them is using the arithmetic operator * (See our paper about > > > Aconcagua. Link: > > > > All good and fine, however the code you posted in this thread suggests > > differently. > > I don't understand what you mean... You said: > 5) Chalten is based on a arithmetic model that allows you to represent time measurements easily (like 3 days, 5 months, etc) So I assumed you meant we could write 5 months just the same way we could write 100 dollars like the examples in the paper show. > > And there is still the question where year comes from > > (please no shared pool). > > I did not see that question, but the answer is No. The variable "year" is > global. The same as month, day, January, February, Monday, etc. Maybe you > will not like it, Global state sucks, no matter how well intended. I haven't tested it but I wouldn't be surprised if it causes problems with Monticello. > but I think that the time domain is so important in > writing software as the arithmetic domain, I think time sucks as a domain. Days that don't have 24 hours, minutes that don't have 60 seconds, years that don't have 365 days, different calendars, timezones, points in time with timezones and without timezones, timezones with more than two DST changes, different week start days, .... For every rule there's an exception and these can change at basically any time. Seriously, how much worse can it get? > so if numbers are global (1, 2, > 3, etc) why not the time objects? They are well know entities of the real > life.... Numbers are literals not global variables. Cheers Philippe > Bye, > Hernan. > > > > Cheers > > Philippe > > > > > > http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=20205775&CFTOKEN=19800555 > > > ) > > > > > > Hope this help. > > > Hernan. > > > > > > > Cheers > > > > Philippe > > > > > > > > > > > These objects are > > > > > > > polymorphic with numbers respect to the arithmetic messages such > as > > > +, > > > > > -, *, > > > > > > > etc., that means that you can use them in arithmetic formulas > > > > > > > > > > > > That's true to a certain extent in Chronos for example you can: > > > > > > Timepoint now - (CalendarDuration months: 1) > > > > > > (CalendarDuration months: 1) * 5 > > > > > > but you can't: > > > > > > 5 * (CalendarDuration months: 1) > > > > > > > > > > Ok, but it is not only the functionality what it is important for > us... > > > for > > > > > us it is also important the way you "write" these things... for > example, > > > > > with Chalten/Aconcagua you can write: > > > > > > > > > > 5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) > > > > > 5 * meter / (second * second) --> A measure of acceleration if you > > > create > > > > > meter as a unit using Aconcagua > > > > > 1/10 * year --> Represents an interest rate of 10% yearly. > > > > > > > > > > As you can see, time measure are not only related only to the time > > > domain > > > > > but used in other domains... that is way for us it is important to > > > support > > > > > this type of behavior and in a DSL way... > > > > > > > > > > Bye, > > > > > Hernan. > > > > > > > > > > > > 5) And of course, I like Chalten's model more that Chronos :-). > For > > > me > > > > > it is > > > > > > > easier to use, but this is just a matter of taste... > > > > > > > > > > > > > > There is a paper we wrote 2 years ago about the problems that > the > > > > > Smalltalk > > > > > > > date classes have and the advantages of having a better model. > If > > > you > > > > > are > > > > > > > interested on having better date and time classes, I recommend > you > > > to > > > > > read > > > > > > > the paper... you may not like it, but at least you will see > other > > > people > > > > > > > ideas... > > > > > > > We use that model (Chalten) in a production system and we > believe it > > > > > allowed > > > > > > > us to avoid many common mistakes related to financial > systems.... > > > but > > > > > hey, > > > > > > > that's just a feeling, nothing I can prove formally. > > > > > > > > > > > > > > I hope you can do something useful. > > > > > > > Bye, > > > > > > > > > > > > Chronos is a bit ugly in Squeak because Squeak does not support > > > > > > namespaces which means that classes that model the same concept as > > > > > > Squeak Chronology classes have different names (unless you mess > with > > > > > > shared pools). Also loading it is a bit of a pain with Monticello > > > > > > (this is the fault of Monticello and not Chronos). > > > > > > > > > > > > Cheers > > > > > > Philippe > > > > > > > > > > > > > Hernan. > > > > > > > > > > > > > > > > > > > > > On 4/16/07, J J <[hidden email] > wrote: > > > > > > > > I have looked at Cronos but it is really huge, and the classes > > > that > > > > > come > > > > > > > > with the image are already very close. I will have to look at > > > > > Chalten, > > > > > > > but > > > > > > > > what is wrong with a few upgrades to the classes that come > with > > > > > Squeak? > > > > > > > > > > > > > > > > >From: "Hernan Wilkinson" < [hidden email]> > > > > > > > > >Reply-To: The general-purpose Squeak developers > > > > > > > > >list< [hidden email] > > > > > > > > > > >To: "The general-purpose Squeak developers > > > > > > > > >list"< [hidden email] > > > > > > > > > > >Subject: Re: Date classes > > > > > > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > > > > > > > > > > > >Before doing something with Date, I recommend you to take a > look > > > at > > > > > > > > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I think > > > Cronos > > > > > too. > > > > > > > > > > > > > > > > > >Hernan. > > > > > > > > > > > > > > > > > >On 4/16/07, J J < [hidden email]> wrote: > > > > > > > > >> > > > > > > > > >>Hi all, > > > > > > > > >> > > > > > > > > >>I am doing some stuff with dates and I noticed the date > classes > > > that > > > > > > > come > > > > > > > > >>with the default Squeak image are very nice and very close > to > > > having > > > > > > > > >>everything I would want. But there are a few > inconsistencies > > > here > > > > > and > > > > > > > > >>there, and things missing that would make things easier. > > > > > > > > >> > > > > > > > > >>So what is the procedure to updating this? I think it's > part of > > > the > > > > > > > core > > > > > > > > >>system so I probably can't just do a monicello package > update > > > > > > > > >>somewhere? Do > > > > > > > > >>I have to do it through mantis? > > > > > > > > >> > > > > > > > > >>Thanks, > > > > > > > > >>Jason > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > >>_________________________________________________________________ > > > > > > > > >>Download Messenger. Join the i'm Initiative. Help make a > > > difference > > > > > > > today. > > > > > > > > > > > > > > > > > > > > > > > > >>http://im.live.com/messenger/im/home/?source=TAGHM_APR07 > > > > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > > Get a FREE Web site, company branded e-mail and more from > > > Microsoft > > > > > Office > > > > > > > > Live! > > > > > > > > > > > > > > > > http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
|
In reply to this post by hernan.wilkinson
But hernan class comments and method comments are good too.
Stef On 17 avr. 07, at 18:00, Hernan Wilkinson wrote: > > > > I loaded Aconcagua-mx.1.6 and Chalten-mx.1.3 in Squeak 3.9. The > following all give errors: > > GregorianDay today + 1 day > GregorianDateTime now + 1 day > GregorianDay today next: 5 > GregorianYear current + 1 year > 5 months > > > I guess I have to thank you. After hearing what a piece of shit > Seaside is because of its lack of documentation it's relieving to see > a framework with no class comments at all. A quick browsing through > same classes showed also no method comments. > > jaja, it seems to me that you did not look good enough.... just > look at the Test!!! They are all the documentation you need! and > more!! real examples, live code! not just documentation.... We > defenetly use different development techniques... Also, remember > the paper! > Links: > <a href="http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%">http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A% > 20New%20Object-Oriented%20Model%20of%20the%20Gregorian%20Calendar.pdf > http://prog2.vub.ac.be/~cderoove/esugtalks/Wilkinson.pdf (ESUG > Presentation) > > About the code you tried: > 1) GregorianDay today + 1 day -> It will not work becuase a date > is not polymorphic with numbers. You have to do: "GregorianDate > today next" or "GregorianDate today next: 1 * day" Remember the *, > that allows you to create measures easily > > 2) GregorianDateTime now + 1 day ---> Same as 1) > > 3) GregorianDay today next: 5 --> It will not work because 5 is not > a measure of time, it is just a number. Try > "GregorianDay today next: 5 * day" 5 * day is a measure of time > > 4) GregorianYear current + 1 year --> Same as 1) but using a > measure expressed in year, for example "2 * year" > 5) 5 months --> Measure are created in many ways. We decided not to > clutter the number protocol with each unit you could have... > because measures are arithmetic representations of a number times > its unit, the right way to create them is using the arithmetic > operator * (See our paper about Aconcagua. Link: > http://portal.acm.org/citation.cfm? > id=1094964&coll=ACM&dl=ACM&CFID=20205775&CFTOKEN=19800555 ) > > Hope this help. > Hernan. > > Cheers > Philippe > > > > > These objects are > > > > polymorphic with numbers respect to the arithmetic messages > such as +, > > -, *, > > > > etc., that means that you can use them in arithmetic formulas > > > > > > That's true to a certain extent in Chronos for example you can: > > > Timepoint now - (CalendarDuration months: 1) > > > (CalendarDuration months: 1) * 5 > > > but you can't: > > > 5 * (CalendarDuration months: 1) > > > > Ok, but it is not only the functionality what it is important for > us... for > > us it is also important the way you "write" these things... for > example, > > with Chalten/Aconcagua you can write: > > > > 5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) > > 5 * meter / (second * second) --> A measure of acceleration if > you create > > meter as a unit using Aconcagua > > 1/10 * year --> Represents an interest rate of 10% yearly. > > > > As you can see, time measure are not only related only to the > time domain > > but used in other domains... that is way for us it is important > to support > > this type of behavior and in a DSL way... > > > > Bye, > > Hernan. > > > > > > 5) And of course, I like Chalten's model more that > Chronos :-). For me > > it is > > > > easier to use, but this is just a matter of taste... > > > > > > > > There is a paper we wrote 2 years ago about the problems that > the > > Smalltalk > > > > date classes have and the advantages of having a better > model. If you > > are > > > > interested on having better date and time classes, I > recommend you to > > read > > > > the paper... you may not like it, but at least you will see > other people > > > > ideas... > > > > We use that model (Chalten) in a production system and we > believe it > > allowed > > > > us to avoid many common mistakes related to financial > systems.... but > > hey, > > > > that's just a feeling, nothing I can prove formally. > > > > > > > > I hope you can do something useful. > > > > Bye, > > > > > > Chronos is a bit ugly in Squeak because Squeak does not support > > > namespaces which means that classes that model the same concept as > > > Squeak Chronology classes have different names (unless you mess > with > > > shared pools). Also loading it is a bit of a pain with Monticello > > > (this is the fault of Monticello and not Chronos). > > > > > > Cheers > > > Philippe > > > > > > > Hernan. > > > > > > > > > > > > On 4/16/07, J J <[hidden email] > wrote: > > > > > I have looked at Cronos but it is really huge, and the > classes that > > come > > > > > with the image are already very close. I will have to look at > > Chalten, > > > > but > > > > > what is wrong with a few upgrades to the classes that come > with > > Squeak? > > > > > > > > > > >From: "Hernan Wilkinson" < [hidden email]> > > > > > >Reply-To: The general-purpose Squeak developers > > > > > >list< [hidden email] > > > > > > >To: "The general-purpose Squeak developers > > > > > >list"< [hidden email] > > > > > > >Subject: Re: Date classes > > > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > > > > > >Before doing something with Date, I recommend you to take > a look at > > > > > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I > think Cronos > > too. > > > > > > > > > > > >Hernan. > > > > > > > > > > > >On 4/16/07, J J < [hidden email]> wrote: > > > > > >> > > > > > >>Hi all, > > > > > >> > > > > > >>I am doing some stuff with dates and I noticed the date > classes that > > > > come > > > > > >>with the default Squeak image are very nice and very > close to having > > > > > >>everything I would want. But there are a few > inconsistencies here > > and > > > > > >>there, and things missing that would make things easier. > > > > > >> > > > > > >>So what is the procedure to updating this? I think it's > part of the > > > > core > > > > > >>system so I probably can't just do a monicello package > update > > > > > >>somewhere? Do > > > > > >>I have to do it through mantis? > > > > > >> > > > > > >>Thanks, > > > > > >>Jason > > > > > >> > > > > > > > > > > > >>_________________________________________________________________ > > > > > >>Download Messenger. Join the i'm Initiative. Help make a > difference > > > > today. > > > > > > > > > > > >>http://im.live.com/messenger/im/home/?source=TAGHM_APR07 > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > Get a FREE Web site, company branded e-mail and more from > Microsoft > > Office > > > > > Live! > > > > > > http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
|
In reply to this post by Ramon Leon-5
Ramon
Philippe is not feeling bad because of that. I hope :) Lukas wrote the first class comment of seaside in my car on the highway to Nice. They know that I'm right on that point. Comments are important. They also know that I respect them and that I pushed a lot seaside. Now liking seaside does not mean that difficult feedback should not be made :) Stef On 17 avr. 07, at 18:34, Ramon Leon wrote: >> I guess I have to thank you. After hearing what a piece of >> shit Seaside is because of its lack of documentation it's >> relieving to see a framework with no class comments at all. A >> quick browsing through same classes showed also no method comments. >> >> Cheers >> Philippe > > Hey, Seaside rocks, hard! Don't let anyone tell you otherwise or > make you > feel bad because of a lack of comments. Comments are nice, but > features are > nicer. You guys do outstanding work, even if it's not said enough, > we're > all thinking it. > > Ramon Leon > http://onsmalltalk.com > > > |
|
|
In reply to this post by Ramon Leon-5
> If there's a lack of comments in the code and on the classes, I
> don't blame them, I blame us, for not jumping in and helping them out. > Would more comments be nice, sure, but lets not make the only guys > doing the > work feel bad about it. Exact! Stef |
|
|
In reply to this post by keith1y
Keith Hodges a écrit :
> >> I don't see a professional coding environment, I see 3 or 4 guys >> contributing their spare time writing one of the most kick ass web >> frameworks ever made. I see check in comments on every commit saying >> what >> they did. If there's a lack of comments in the code and on the >> classes, I >> don't blame them, I blame us, for not jumping in and helping them out. >> Would more comments be nice, sure, but lets not make the only guys >> doing the >> work feel bad about it. >> >> > Kick ass web frameworks for whom, the elite? the premadonnas? What > happened to smalltalk being an environment that is so easy a child could > do it, making things accessible as part of the culture? > Hi Keith, I agree, a nice goal. But you must take into account that external world do impose constraints. I'am not sure Seaside team is responsible for WEB complexity. They just try to manage it. And to come back to Date subject our days are still more or less 86400 seconds, night included. So I would not rant Seaside people for not working hard enough. Nicolas |
|
|
In reply to this post by Philippe Marschall
On 4/17/07, Philippe Marschall <[hidden email]> wrote: You said: No "5 months" but "5 * months" or "moth with: 5". Same for "dollars", "euros", "meters", "liters", "A", "B", etc. That is why I think that measure was not a good word to define this objects... 5*A is not a measure.. what we implemented is really an algebra, maybe a limited one, but an algebra at the end. > > And there is still the question where year comes from Well, I do not agree... I used to think like that but I've changed my mind... Object should be global if the entity they represent in real life is global... but I understand that you don't like them. From an Software Engineering point of view, global variables are not good... but if you think software development as a learning process and you see the Smalltalk image as the "state" of your knowledge about a specific domain(s), having global objects (well know objects) is not bad.... > but I think that the time domain is so important in I believe it is a really interesting domain!! because of the things you mention! because the exceptions it has makes it a very interesting and challenging problem to design. > so if numbers are global (1, 2, Well... that's an implementation detail... at the end they are global. They are not "global variables" but "global objects" because the parser knows about them.... so, at the end, they are global. And I think it is ok for them to be global because it is almost impossible to think about a programming language without numbers.... when we get a programming language we are expecting to have at least the math to be model with it... (a programming language without numbers as primitives is a very challenging idea... I don't know if it is feasible...) Anyhow, I think that when your knowledge about a problem domain (Smalltalk image) is mature, you will end up with some global objects... We develop financial software and I have to tell you that having "dollar", "euro", etc. as global objects would help us a lot... for example no need to declare them on each unit test (of course we use test resources, but still), no need for the final user to define them (they expect dollar, euro, peso, etc. as part of the "kit")... Bye, Hernan. Cheers |
|
|
In reply to this post by Nicolas Cellier-3
> And to come back to Date subject our days are still more or less 86400 > seconds, night included. So I would not rant Seaside people for not > working hard enough. > > Nicolas It's not a rant about people not working hard enough. Many people perceive that Test first development must require 'more work'. Those that swear by test first development might disagree. The same goes for most other practices which have a counter intuitive payoff (e.g. pair programming etc) I do not think that it has anything to do with working hard enough, it has to do with attitude, and culture. In smalltalk we have a culture that accepts this, because we can I guess. cheers Keith |
|
|
In reply to this post by hernan.wilkinson
2007/4/17, Hernan Wilkinson <[hidden email]>:
> > > On 4/17/07, Philippe Marschall <[hidden email]> wrote: > > You said: > > > 5) Chalten is based on a arithmetic model that allows you to represent > time measurements easily (like 3 days, 5 months, etc) > > > > So I assumed you meant we could write > > 5 months > > just the same way we could write > > 100 dollars > > like the examples in the paper show. > > No "5 months" but "5 * months" or "moth with: 5". Same for "dollars", > "euros", "meters", "liters", "A", "B", etc. > That is why I think that measure was not a good word to define this > objects... 5*A is not a measure.. what we implemented is really an algebra, > maybe a limited one, but an algebra at the end. Maybe I'm just seeing things: http://www.iam.unibe.ch/~ducasse/Teaching/CoursAnnecy/0506-M1-COO/A%20New%20Object-Oriented%20Model%20of%20the%20Gregorian%20Calendar.pdf page 7, figure 11: 14 days + 1 week = 1814400000 milliseconds. "Adding measurements of the same base unit" ((14 days + 1 week) convertTo: days) = 21 days. "Converting the result of an operation" (1 year + 10 days) = (1 year + 10 days) "Adding measurements of different base unit" 10 years * 10 = 100 years "Multiplying a measurement by a number" 10 years * 12 months = 10 year*year "Multiplying measurements" 10 years * 12 months / 24 months = 5 years "The model automatically simplifies units" 100 kilometers / 1 hour "Represents a speed of 100 km per hour" 0.01 / 1 month "Represent an interest rate of 10 % by month" page 8, figure 12: (GregorianYear number: 2005) next: 1 year "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 12 months "Returns GregorianYear number: 2006" (GregorianYear number: 2005) next: 10 years "Returns GregorianYear number: 2015" (GregorianYear number: 2005) previous: 5 years "Returns GregorianYear number: 2000" page 8, figure 13: (GregorianYear number: 2005) next: 120 days "Signals an exception because 120 days can not be converted to years" '01/2005' asGregorianMonthOfYear next: 120 days "Signals an exception because 120 days can not be converted to months" page 8, figure 14: GregorianDay monday next: 4 days "Returns Friday" GregorianMonth january next: 2 months "Returns March" (GregorianMonth january dayNumber: 1) next: 2 days "Returns January 3rd " page 8, figure 17: "Returns an Interval with six elements, the years 2005,2007,2009,2011,2013 and 2015 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2015) by: 2 years "Returns an Interval with six elements, the years 2005,2004,2003,2002,2001 and 2000 inclusive". (GregorianYear number: 2005) to: (GregorianYear number: 2000) by: -1 year page 10, figure 22: "06/01/2005 is a Thursday" aTimespan := Timespan from: '06/01/2005' asGregorianDate duration: 48 hours. > > > > And there is still the question where year comes from > > > > (please no shared pool). > > > > > > I did not see that question, but the answer is No. The variable "year" > is > > > global. The same as month, day, January, February, Monday, etc. Maybe > you > > > will not like it, > > > > Global state sucks, no matter how well intended. I haven't tested it > > but I wouldn't be surprised if it causes problems with Monticello. > > Well, I do not agree... I used to think like that but I've changed my > mind... Object should be global if the entity they represent in real life is > global... but I understand that you don't like them. > From an Software Engineering point of view, global variables are not good... > but if you think software development as a learning process and you see the > Smalltalk image as the "state" of your knowledge about a specific domain(s), > having global objects (well know objects) is not bad.... > > > > but I think that the time domain is so important in > > > writing software as the arithmetic domain, > > > > I think time sucks as a domain. Days that don't have 24 hours, minutes > > that don't have 60 seconds, years that don't have 365 days, different > > calendars, timezones, points in time with timezones and without > > timezones, timezones with more than two DST changes, different week > > start days, .... For every rule there's an exception and these can > > change at basically any time. Seriously, how much worse can it get? > > > I believe it is a really interesting domain!! because of the things you > mention! because the exceptions it has makes it a very interesting and > challenging problem to design. Well, yeah. I just don't see how Chalten addresses many of these. Eg. it assumes days have 24 hours and minutes have 60 seconds. > > > so if numbers are global (1, 2, > > > 3, etc) why not the time objects? They are well know entities of the > real > > > life.... > > > > Numbers are literals not global variables. > > Well... that's an implementation detail... at the end they are global. They > are not "global variables" but "global objects" because the parser knows > about them.... so, at the end, they are global. And I think it is ok for > them to be global because it is almost impossible to think about a > programming language without numbers.... when we get a programming language > we are expecting to have at least the math to be model with it... (a > programming language without numbers as primitives is a very challenging > idea... I don't know if it is feasible...) I don't agree because they don't have the semantics of globals like identify (for everything but SmallIntegers). The compiler/parser knows about them, that's all. But that certainly depends of POV. > Anyhow, I think that when your knowledge about a problem domain (Smalltalk > image) is mature, you will end up with some global objects... We develop > financial software and I have to tell you that having "dollar", "euro", etc. > as global objects would help us a lot... for example no need to declare them > on each unit test (of course we use test resources, but still), no need for > the final user to define them (they expect dollar, euro, peso, etc. as part > of the "kit")... Why don't you have them as global objects then? Cheers Philippe > Bye, > Hernan. > > > Cheers > > Philippe > > > > > Bye, > > > Hernan. > > > > > > > > > > Cheers > > > > Philippe > > > > > > > > > > > > > http://portal.acm.org/citation.cfm?id=1094964&coll=ACM&dl=ACM&CFID=20205775&CFTOKEN=19800555 > > > > > ) > > > > > > > > > > Hope this help. > > > > > Hernan. > > > > > > > > > > > Cheers > > > > > > Philippe > > > > > > > > > > > > > > > These objects are > > > > > > > > > polymorphic with numbers respect to the arithmetic messages > such > > > as > > > > > +, > > > > > > > -, *, > > > > > > > > > etc., that means that you can use them in arithmetic > formulas > > > > > > > > > > > > > > > > That's true to a certain extent in Chronos for example you > can: > > > > > > > > Timepoint now - (CalendarDuration months: 1) > > > > > > > > (CalendarDuration months: 1) * 5 > > > > > > > > but you can't: > > > > > > > > 5 * (CalendarDuration months: 1) > > > > > > > > > > > > > > Ok, but it is not only the functionality what it is important > for > > > us... > > > > > for > > > > > > > us it is also important the way you "write" these things... for > > > example, > > > > > > > with Chalten/Aconcagua you can write: > > > > > > > > > > > > > > 5 * month ---> Equivalent to 5 * (CalendarDuration months: 1) > > > > > > > 5 * meter / (second * second) --> A measure of acceleration if > you > > > > > create > > > > > > > meter as a unit using Aconcagua > > > > > > > 1/10 * year --> Represents an interest rate of 10% yearly. > > > > > > > > > > > > > > As you can see, time measure are not only related only to the > time > > > > > domain > > > > > > > but used in other domains... that is way for us it is important > to > > > > > support > > > > > > > this type of behavior and in a DSL way... > > > > > > > > > > > > > > Bye, > > > > > > > Hernan. > > > > > > > > > > > > > > > > 5) And of course, I like Chalten's model more that Chronos > :-). > > > For > > > > > me > > > > > > > it is > > > > > > > > > easier to use, but this is just a matter of taste... > > > > > > > > > > > > > > > > > > There is a paper we wrote 2 years ago about the problems > that > > > the > > > > > > > Smalltalk > > > > > > > > > date classes have and the advantages of having a better > model. > > > If > > > > > you > > > > > > > are > > > > > > > > > interested on having better date and time classes, I > recommend > > > you > > > > > to > > > > > > > read > > > > > > > > > the paper... you may not like it, but at least you will see > > > other > > > > > people > > > > > > > > > ideas... > > > > > > > > > We use that model (Chalten) in a production system and we > > > believe it > > > > > > > allowed > > > > > > > > > us to avoid many common mistakes related to financial > > > systems.... > > > > > but > > > > > > > hey, > > > > > > > > > that's just a feeling, nothing I can prove formally. > > > > > > > > > > > > > > > > > > I hope you can do something useful. > > > > > > > > > Bye, > > > > > > > > > > > > > > > > Chronos is a bit ugly in Squeak because Squeak does not > support > > > > > > > > namespaces which means that classes that model the same > concept as > > > > > > > > Squeak Chronology classes have different names (unless you > mess > > > with > > > > > > > > shared pools). Also loading it is a bit of a pain with > Monticello > > > > > > > > (this is the fault of Monticello and not Chronos). > > > > > > > > > > > > > > > > Cheers > > > > > > > > Philippe > > > > > > > > > > > > > > > > > Hernan. > > > > > > > > > > > > > > > > > > > > > > > > > > > On 4/16/07, J J <[hidden email] > wrote: > > > > > > > > > > I have looked at Cronos but it is really huge, and the > classes > > > > > that > > > > > > > come > > > > > > > > > > with the image are already very close. I will have to > look at > > > > > > > Chalten, > > > > > > > > > but > > > > > > > > > > what is wrong with a few upgrades to the classes that come > > > with > > > > > > > Squeak? > > > > > > > > > > > > > > > > > > > > >From: "Hernan Wilkinson" < [hidden email]> > > > > > > > > > > >Reply-To: The general-purpose Squeak developers > > > > > > > > > > >list< > [hidden email] > > > > > > > > > > > > > > >To: "The general-purpose Squeak developers > > > > > > > > > > >list"< > [hidden email] > > > > > > > > > > > > > > >Subject: Re: Date classes > > > > > > > > > > >Date: Mon, 16 Apr 2007 14:28:09 -0300 > > > > > > > > > > > > > > > > > > > > > >Before doing something with Date, I recommend you to take > a > > > look > > > > > at > > > > > > > > > > >"Chalten" or "Cronos". Chalten is in SqueakSource.... I > think > > > > > Cronos > > > > > > > too. > > > > > > > > > > > > > > > > > > > > > >Hernan. > > > > > > > > > > > > > > > > > > > > > >On 4/16/07, J J < [hidden email]> wrote: > > > > > > > > > > >> > > > > > > > > > > >>Hi all, > > > > > > > > > > >> > > > > > > > > > > >>I am doing some stuff with dates and I noticed the date > > > classes > > > > > that > > > > > > > > > come > > > > > > > > > > >>with the default Squeak image are very nice and very > close > > > to > > > > > having > > > > > > > > > > >>everything I would want. But there are a few > > > inconsistencies > > > > > here > > > > > > > and > > > > > > > > > > >>there, and things missing that would make things easier. > > > > > > > > > > >> > > > > > > > > > > >>So what is the procedure to updating this? I think it's > > > part of > > > > > the > > > > > > > > > core > > > > > > > > > > >>system so I probably can't just do a monicello package > > > update > > > > > > > > > > >>somewhere? Do > > > > > > > > > > >>I have to do it through mantis? > > > > > > > > > > >> > > > > > > > > > > >>Thanks, > > > > > > > > > > >>Jason > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>_________________________________________________________________ > > > > > > > > > > >>Download Messenger. Join the i'm Initiative. Help make a > > > > > difference > > > > > > > > > today. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >> > http://im.live.com/messenger/im/home/?source=TAGHM_APR07 > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _________________________________________________________________ > > > > > > > > > > Get a FREE Web site, company branded e-mail and more from > > > > > Microsoft > > > > > > > Office > > > > > > > > > > Live! > > > > > > > > > > > > > > > > > > > > > > > > > http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |
|
|
On 4/18/07, Philippe Marschall <[hidden email]> wrote: 2007/4/17, Hernan Wilkinson <[hidden email]>: ups... you are right, the papers were written before we implemented the #* message to create measures... that's why documentation is not good! :-) (Hey, just kidding, I don't want to get into that discussion again...) > > > > And there is still the question where year comes from Yes, as I said, it is a model of the GREGORIAN CALENDAR, and in that calendar, days have 24 hours and minutes 60 seconds... > > > so if numbers are global (1, 2, I don't understand this... anyhow, at the end, from a conceptual point of view, they are global objects (no global variables... I see variables just as names we give to objects...) The compiler/parser knows > Anyhow, I think that when your knowledge about a problem domain (Smalltalk Because software evolution is not simple you know... and because not everybody in the team agrees with me!!! :-). Well, it was nice to talk about this issues with you. Bye, Hernan. Cheers |
|
|
In reply to this post by hernan.wilkinson
>From: "Hernan Wilkinson" <[hidden email]>
>Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: Date classes >Date: Tue, 17 Apr 2007 10:10:49 -0300 > >There is a paper we wrote 2 years ago about the problems that the Smalltalk >date classes have and the advantages of having a better model. If you are >interested on having better date and time classes, I recommend you to read >the paper... you may not like it, but at least you will see other people >ideas... Hi. Any link to the paper? And my choice is not about what I like or what I don't like, it's about external dependencies. I am creating Recurrence rules in Squeak (very hairy specification) and I want to minimize external dependencies. I didn't want to say someone has to use some special time package (no matter how good it is) just to use my stuff. Especially since I don't see Recurrence rules needing that extra functionality (e.g. timezones). _________________________________________________________________ Get a FREE Web site, company branded e-mail and more from Microsoft Office Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ |
|
|
In reply to this post by hernan.wilkinson
Oh, and thanks for the information.
>From: "Hernan Wilkinson" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "The general-purpose Squeak developers >list"<[hidden email]> >Subject: Re: Date classes >Date: Tue, 17 Apr 2007 10:10:49 -0300 > >Just to give you a fast review of what I remember (I developed the model >that Maxi Taborda converted into Chalten): >1) Chronos supports many calendars, Chalten only the Gregorian Calendar >2) Chronos supports time zones, Chalten does not >3) Choros is huge (as you mentions), Chalten is more manageable (because it >just model the Gregorian Calendar) >4) Chronos lacks some abstractions that Chalten has, like Day of Month and >others (I don't remember now...there are a couple of mails that I and the >guy that created Chronos wrote about these issues, like one year ago) >5) Chalten is based on a arithmetic model that allows you to represent time >measurements easily (like 3 days, 5 months, etc). These objects are >polymorphic with numbers respect to the arithmetic messages such as +, -, >*, >etc., that means that you can use them in arithmetic formulas >5) And of course, I like Chalten's model more that Chronos :-). For me it >is >easier to use, but this is just a matter of taste... > >There is a paper we wrote 2 years ago about the problems that the Smalltalk >date classes have and the advantages of having a better model. If you are >interested on having better date and time classes, I recommend you to read >the paper... you may not like it, but at least you will see other people >ideas... >We use that model (Chalten) in a production system and we believe it >allowed >us to avoid many common mistakes related to financial systems.... but hey, >that's just a feeling, nothing I can prove formally. > >I hope you can do something useful. >Bye, >Hernan. > > >On 4/16/07, J J <[hidden email]> wrote: >> >>I have looked at Cronos but it is really huge, and the classes that come >>with the image are already very close. I will have to look at Chalten, >>but >>what is wrong with a few upgrades to the classes that come with Squeak? >> >> >From: "Hernan Wilkinson" <[hidden email]> >> >Reply-To: The general-purpose Squeak developers >> >list<[hidden email]> >> >To: "The general-purpose Squeak developers >> >list"<[hidden email]> >> >Subject: Re: Date classes >> >Date: Mon, 16 Apr 2007 14:28:09 -0300 >> > >> >Before doing something with Date, I recommend you to take a look at >> >"Chalten" or "Cronos". Chalten is in SqueakSource.... I think Cronos >>too. >> > >> >Hernan. >> > >> >On 4/16/07, J J <[hidden email]> wrote: >> >> >> >>Hi all, >> >> >> >>I am doing some stuff with dates and I noticed the date classes that >>come >> >>with the default Squeak image are very nice and very close to having >> >>everything I would want. But there are a few inconsistencies here and >> >>there, and things missing that would make things easier. >> >> >> >>So what is the procedure to updating this? I think it's part of the >>core >> >>system so I probably can't just do a monicello package update >> >>somewhere? Do >> >>I have to do it through mantis? >> >> >> >>Thanks, >> >>Jason >> >> >> >>_________________________________________________________________ >> >>Download Messenger. Join the i'm Initiative. Help make a difference >>today. >> >>http://im.live.com/messenger/im/home/?source=TAGHM_APR07 >> >> >> >> >> >> >> >> >> > >> >>_________________________________________________________________ >>Get a FREE Web site, company branded e-mail and more from Microsoft Office >>Live! http://clk.atdmt.com/MRT/go/mcrssaub0050001411mrt/direct/01/ >> >> >> > _________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John. Enter to win today. http://msnconcertcontest.com?icid-nceltontagline |
|
|
In reply to this post by Ramon Leon-5
I think the problem we are seeing is that we don't really have a distinction
between "stable" and "live branch" in Seaside right now. I think what happens in most OS projects is when a branch moves to "stable" (i.e. no new features added to the branch, just bug fixes) then the documentation team can come in and make sure the documentation is 100% because the target isn't moving so much anymore. The main Seaside branch is moving so fast documenting it would be a situation where; before you can publish the change set with the documentation, much of it is already invalid. I think we need to have a separate group doing the documentation if possible, these guys are on a role, we should let them keep at it. >From: "Ramon Leon" <[hidden email]> >Reply-To: The general-purpose Squeak developers >list<[hidden email]> >To: "'The general-purpose Squeak developers >list'"<[hidden email]> >Subject: RE: Date classes >Date: Tue, 17 Apr 2007 10:37:35 -0700 > > > "But if it is not documented it may as well not exist" - so > > the features you mention that are so great actually for real > > purposes (apart from personal hacking) do not exist! > >Not true. They've been doing lots of stuff lately to improve performance. >We all benefit from that whether they document it or not. > > > When you are working in a professional coding environment, > > anything without documentation falls below the radar. > > Management cant keep looking at source code to see if a > > needed feature has arrived. > > > > best regards > > > > Keith > >I don't see a professional coding environment, I see 3 or 4 guys >contributing their spare time writing one of the most kick ass web >frameworks ever made. I see check in comments on every commit saying what >they did. If there's a lack of comments in the code and on the classes, I >don't blame them, I blame us, for not jumping in and helping them out. >Would more comments be nice, sure, but lets not make the only guys doing >the >work feel bad about it. > >Ramon Leon >http://onsmalltalk.com > > _________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 |
|
|
2007/4/20, J J <[hidden email]>:
> I think the problem we are seeing is that we don't really have a distinction > between "stable" and "live branch" in Seaside right now. I think what > happens in most OS projects is when a branch moves to "stable" (i.e. no new > features added to the branch, just bug fixes) then the documentation team > can come in and make sure the documentation is 100% because the target isn't > moving so much anymore. stable: Seaside 2.7 live: Seaside 2.8 > The main Seaside branch is moving so fast documenting it would be a > situation where; before you can publish the change set with the > documentation, much of it is already invalid. No > I think we need to have a separate group doing the documentation if > possible, these guys are on a role, we should let them keep at it. We are happy for any help. Cheers Philippe > >From: "Ramon Leon" <[hidden email]> > >Reply-To: The general-purpose Squeak developers > >list<[hidden email]> > >To: "'The general-purpose Squeak developers > >list'"<[hidden email]> > >Subject: RE: Date classes > >Date: Tue, 17 Apr 2007 10:37:35 -0700 > > > > > "But if it is not documented it may as well not exist" - so > > > the features you mention that are so great actually for real > > > purposes (apart from personal hacking) do not exist! > > > >Not true. They've been doing lots of stuff lately to improve performance. > >We all benefit from that whether they document it or not. > > > > > When you are working in a professional coding environment, > > > anything without documentation falls below the radar. > > > Management cant keep looking at source code to see if a > > > needed feature has arrived. > > > > > > best regards > > > > > > Keith > > > >I don't see a professional coding environment, I see 3 or 4 guys > >contributing their spare time writing one of the most kick ass web > >frameworks ever made. I see check in comments on every commit saying what > >they did. If there's a lack of comments in the code and on the classes, I > >don't blame them, I blame us, for not jumping in and helping them out. > >Would more comments be nice, sure, but lets not make the only guys doing > >the > >work feel bad about it. > > > >Ramon Leon > >http://onsmalltalk.com > > > > > > _________________________________________________________________ > Exercise your brain! Try Flexicon. > http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 > > > |
|
|
In reply to this post by Andreas.Raab
On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote:
> Keith Hodges wrote: > >J J wrote: > >>I have looked at Cronos but it is really huge, and the classes that > >>come with the image are already very close. I will have to look at > >>Chalten, but what is wrong with a few upgrades to the classes that > >>come with Squeak? > >Absolutely nothing, the squeak classes recently had a fairly > >comprehensive rewrite, and are still essentially a 1.0 release, it > >should be expected that some updates and improvements are desired. There > >is plenty of room for these base classes to evolve. For example I would > >also propose a split in the packaging of these classes so there can be > >an absolute minimum Kernel version for KernelImages as well as a fully > >featured version. > > I have been experimenting with this idea recently and the bottom line is > that all you *really* need is access to the millisecond clock primitive > (for Delay and friends). Pretty much everything else can be built on top > of that without access to more elaborate Date and Time classes. Moving > #millisecondClockValue into, say, Delay would make a great starting > point to rip out all of the Chronology classes for a minimal image. This is true if and only if the millisecond clock is a monotonically increasing function. That is not the case for the Squeak VM, which presents a "local time" version of the clock. Thus for example durations that cross daylight savings time transitions are problematic. If we change to a millisecond clock that represents UTC time rather than local time, then you are absolutely right. Dave |
|
|
David T. Lewis wrote:
> On Mon, Apr 16, 2007 at 04:42:25PM -0700, Andreas Raab wrote: >> I have been experimenting with this idea recently and the bottom line is >> that all you *really* need is access to the millisecond clock primitive >> (for Delay and friends). Pretty much everything else can be built on top >> of that without access to more elaborate Date and Time classes. Moving >> #millisecondClockValue into, say, Delay would make a great starting >> point to rip out all of the Chronology classes for a minimal image. > > This is true if and only if the millisecond clock is a monotonically > increasing function. That is not the case for the Squeak VM, which > presents a "local time" version of the clock. Thus for example durations > that cross daylight savings time transitions are problematic. If we > change to a millisecond clock that represents UTC time rather than > local time, then you are absolutely right. I'm not getting your point. Why is having a monotonically increasing msecs clock a requirement? What I meant to say is that the only dependency I can't think to get rid of is the millisecond clock and only because it's tied so intrinsically to Delay which itself is tied intrinsically to Semaphore and Process. Which, even for a minimal image, you probably can't get rid of ;-) But it seems to me that whether the msecs clock is monotonically increasing or not is independent of that. Cheers, - Andreas |
|
|
In reply to this post by David T. Lewis
The real problem is that the millisecond clock overturns back to 0
isn't it? That and the fact there's no way to detect when it does. I didn't test it, but I'd be surprised if changing the computer clock has any effect on Time millisecondClockValue.. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |