October 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] "Conceptually the same as" in Smalltalk

by Alexandre Bergel

Hi Sean, This is a complex question. Essentially, this is the difference between a plain normal class and an abstract data type. Abstract data type will typically override hash and = to give the ability to structurally compare them. >From my rather long experience in programming, I do not remember to have overriding = and hash, even once. This is error prone and not justified. Also, if you have two different objects that are equals, then it often leads to complex situation to debug (Have you ever used âTranscript show: my object hash asStringâ?). In your case of Person, I guess each person has to have a unique Id (social number?). This is how I would solve this. Cheers, Alexandre On Oct 2, 2014, at 4:41 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I've read that #= can ignore non-domain things like cache data, but what > about domain-related things that do not effect identity? > > Let's say I have a Person class. Obviously, the #name would be compared in > #=. But what if there was a collection of #phoneNumbers, and aPerson and > anotherPerson differed only in that one of them had been updated with an > extra #phoneNumber? Should #= answer true or false? I'm guessing true since > e.g. in a unique collection there should only be one of that particular > person. Then there would have to be another message like #exactlyTheSameAs:. > Is there a well-known pattern distinguishing "Conceptually the same as" from > "exactly the same as, but not #=="? > > Thanks. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Conceptually-the-same-as-in-Smalltalk-tp4782118.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Esteban Lorenzano

HI, Well, what you say sounds harsh... but is not too far from truth, sadly. What happens is that current manpower for every task is very limited (it's me)... and well, urgent stuff is always hunting us. We have the willing, and we have spent some time on it, but it will be a lot easier if there is also community effort put on improve things... every single bugfix, comment or whatever helps, but also more important efforts are needed. We would bless any effort/collaboration in that direction. I suppose we can also put bounties to fulfil certain tasks (that's how first DBXTalk suite was made). To have a description of what we need (a list of features, etc.) would be cool too. cheers, Esteban On Thu, Oct 2, 2014 at 10:26 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Esteban, > > On 02 Oct 2014, at 20:43, Esteban A. Maringolo <emaringolo(a)gmail.com> > wrote: > > > 2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > >> Esteban wrote: > >>> Are you using/planning to use PostgresV3? > >> > >>> What are its advantages over current driver (PostgresV2)? > >> > >> I was puzzled that a smart developer like Levente > >> decides not to use Glorp. > > > > I don't want to sound harsh, but there is no VISIBLE interest from the > > Pharo board/committee regarding ORM and/or RDBMS support other than a > > CI task. Few days ago I asked a question in the Pharo-Business > > regarding this, and got NO REPLY. > > > > This week I was looking into Python's SQLAlchemy [1] to find how close > > it is to GLORP current features, and also found out how far it > > seems/feels to a small > > community like ours. Not to mention things like jOOQ[2] ([1] provides > > some of its features though). > > > > I'm making no demands here, just giving my opinion about a "business > > feature" (DBs) that I'd like better supported. > > I understand your pain, you're looking for people that are in the same > boat, apparently there aren't that many. But there certainly are some (I > use(d) Glorp+PostgresV2 myself, I believe Mariano does too), but it seems > nobody wants to take the lead to push this (even) further. I am not sure > this is necessarily bad, RDBMS does not move that much, but it would > obviously be better to have more users. > > We are a small(er) community, it is what it is, but we are growing. > > >> And I wondered why SqueakDBX decided to use V2 instead of V3, > >> a protocol introduced in 2003 or so. > > > > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > > the Squeak community? > > I know something changed in PgSQL protocols around version 7.2. > > V2 and V3 are indeed two different wire level protocols for a DB client to > talk to PostgreSQL. Obviously, V3 came after V2, it should be considered an > improvement, but V2 remains supported. As far as I understood it, V3 is > binary while V2 is text oriented, the former should be faster. I am sure > there are feature lists comparing the two somewhere out there. > > Of course, the implementation quality of the driver is important too to > get good performance. > > We'll see how far Stephan gets, I am interested. I really hope we can get > the V3 code running in Pharo without too much compatibility issues. > > > Esteban A. Maringolo > > [1] http://www.sqlalchemy.org/ > > [2] http://www.jooq.org/ > > Sven > > >

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Sven Van Caekenberghe

Esteban, On 02 Oct 2014, at 20:43, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > 2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: >> Esteban wrote: >>> Are you using/planning to use PostgresV3? >> >>> What are its advantages over current driver (PostgresV2)? >> >> I was puzzled that a smart developer like Levente >> decides not to use Glorp. > > I don't want to sound harsh, but there is no VISIBLE interest from the > Pharo board/committee regarding ORM and/or RDBMS support other than a > CI task. Few days ago I asked a question in the Pharo-Business > regarding this, and got NO REPLY. > > This week I was looking into Python's SQLAlchemy [1] to find how close > it is to GLORP current features, and also found out how far it > seems/feels to a small > community like ours. Not to mention things like jOOQ[2] ([1] provides > some of its features though). > > I'm making no demands here, just giving my opinion about a "business > feature" (DBs) that I'd like better supported. I understand your pain, you're looking for people that are in the same boat, apparently there aren't that many. But there certainly are some (I use(d) Glorp+PostgresV2 myself, I believe Mariano does too), but it seems nobody wants to take the lead to push this (even) further. I am not sure this is necessarily bad, RDBMS does not move that much, but it would obviously be better to have more users. We are a small(er) community, it is what it is, but we are growing. >> And I wondered why SqueakDBX decided to use V2 instead of V3, >> a protocol introduced in 2003 or so. > > Is the V2/V3 spec a PostgreSQL protocol spec or something made up in > the Squeak community? > I know something changed in PgSQL protocols around version 7.2. V2 and V3 are indeed two different wire level protocols for a DB client to talk to PostgreSQL. Obviously, V3 came after V2, it should be considered an improvement, but V2 remains supported. As far as I understood it, V3 is binary while V2 is text oriented, the former should be faster. I am sure there are feature lists comparing the two somewhere out there. Of course, the implementation quality of the driver is important too to get good performance. We'll see how far Stephan gets, I am interested. I really hope we can get the V3 code running in Pharo without too much compatibility issues. > Esteban A. Maringolo > [1] http://www.sqlalchemy.org/ > [2] http://www.jooq.org/ Sven

Oct. 2, 2014

"Conceptually the same as" in Smalltalk

by Sean P. DeNigris

I've read that #= can ignore non-domain things like cache data, but what about domain-related things that do not effect identity? Let's say I have a Person class. Obviously, the #name would be compared in #=. But what if there was a collection of #phoneNumbers, and aPerson and anotherPerson differed only in that one of them had been updated with an extra #phoneNumber? Should #= answer true or false? I'm guessing true since e.g. in a unique collection there should only be one of that particular person. Then there would have to be another message like #exactlyTheSameAs:. Is there a well-known pattern distinguishing "Conceptually the same as" from "exactly the same as, but not #=="? Thanks. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Conceptually-the-same-as-in-Smalltalk-tp4782118.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Oct. 2, 2014

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Udo Schneider

On 02.10.14 18:17, Damien Cassou wrote: > you should have received an invitation Yepp - I did. Already committed the Blog entry 1:1. Working on cleaning up the language now. BTW: Is there any guide regarding the kind of language (e.g. tonality) of the book. I'd change the it given the fact that the blog entry is pretty informal which is IMHO not appropriate for a book ... Thanks, Udo

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Esteban A. Maringolo

2014-10-02 15:19 GMT-03:00 Stephan Eggermont <stephan(a)stack.nl>: > Esteban wrote: >>Are you using/planning to use PostgresV3? > >>What are its advantages over current driver (PostgresV2)? > > I was puzzled that a smart developer like Levente > decides not to use Glorp. I don't want to sound harsh, but there is no VISIBLE interest from the Pharo board/committee regarding ORM and/or RDBMS support other than a CI task. Few days ago I asked a question in the Pharo-Business regarding this, and got NO REPLY. This week I was looking into Python's SQLAlchemy [1] to find how close it is to GLORP current features, and also found out how far it seems/feels to a small community like ours. Not to mention things like jOOQ[2] ([1] provides some of its features though). I'm making no demands here, just giving my opinion about a "business feature" (DBs) that I'd like better supported. > And I wondered why SqueakDBX decided to use V2 instead of V3, > a protocol introduced in 2003 or so. Is the V2/V3 spec a PostgreSQL protocol spec or something made up in the Squeak community? I know something changed in PgSQL protocols around version 7.2. Esteban A. Maringolo [1] http://www.sqlalchemy.org/ [2] http://www.jooq.org/

Oct. 2, 2014

Re: [Pharo-users] Parsing SQL in a Pharo system

by Stephan Eggermont

Esteban wrote: >Are you using/planning to use PostgresV3? >What are its advantages over current driver (PostgresV2)? I was puzzled that a smart developer like Levente decides not to use Glorp. And I wondered why SqueakDBX decided to use V2 instead of V3, a protocol introduced in 2003 or so. Stephan

Oct. 2, 2014

Re: [Pharo-users] Pharo days: date proposal

by Marcus Denker

On 02 Oct 2014, at 18:30, Stephan Eggermont <stephan(a)stack.nl> wrote: > That combines well with FOSDEM, which is the next two days in Bruxelles. > Yesterday I got a mail that we'll be having a smalltalk room on Sunday. > That is nice! Marcus

Oct. 2, 2014

Re: [Pharo-users] Pharo days: date proposal

by Stephan Eggermont

That combines well with FOSDEM, which is the next two days in Bruxelles. Yesterday I got a mail that we'll be having a smalltalk room on Sunday. Stephan

Oct. 2, 2014

Re: [Pharo-users] BLOG: Block Translators - parsing magic

by Damien Cassou

On Wed, Oct 1, 2014 at 5:53 PM, Udo Schneider <udo.schneider(a)homeaddress.de> wrote: > I'll check the project structure and tell you. But I assume I'd prefer > working directly - even if in "my" directory only. you should have received an invitation -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Oct. 2, 2014