June 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

Besides several TBehavior-like traits with more than one user in the kernel (TApplyingOnClassSide TBehavior TClass TClassDescription TComposingDescription) we have some more general ones (TSortable TTranscript). So we will have some code duplicities. -- Pavel 2017-06-27 15:13 GMT+02:00 Guillermo Polito <guillermopolito(a)gmail.com>: > But that's not the case. The only usage of traits in the Kernel is > TBehaviour, to share some common behaviour between traits and classes. But > Pablo is working on a new modular implementation of traits that would not > require TBehavior, and would simplify the code of classes. > > On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> > wrote: > >> >> El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> escribiÃ³: >> >> >> >> 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: >> >>> Just for curiosity: Is it a good decision? It is supposed that with >>> Traits we can have less code duplication. And maybe the code duplication >>> happens also in the Pharo kernel, right? >>> >>> Thanks for any explanation :-) >>> >> >> You are right, it will cause more code duplicities in the kernel. On the >> other hand we will be able to clean the traits implementation and make it >> more modular, so the users will have more options like stateful traits, >> talents etc. We needed to do a small step back to be able to move forward. >> It was not an easy decision but it was planned for a long time. And in >> the end, this decision was done by people who introduced traits and >> invested a lot of time and effort into them. >> >> >> Thatâs interesting. Thanks for the explanation :-) >> >> Juraj >> >> >> -- Pavel >> >> >> >>> >>> Cheers, >>> Juraj >>> >>> > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> >>> escribiÃ³: >>> > >>> > Hi, >>> > >>> > because we want to have traits only as an option where people will be >>> able to choose custom traits implementation, the Pharo kernel cannot depend >>> on them. For that reason we had to flatten all classes that use traits in >>> the kernel packages. >>> > That means that methods from system traits as TBehavior [1] were >>> copied to the trait users and the traits were removed from the class >>> definitions. For now these traits are still present in the image. >>> > If you use own traits in your projects, this step will have no impact >>> on you. Only if your project extends the system traits, you will need to >>> adopt it for Pharo 7. >>> > >>> > [1] complete list: TApplyingOnClassSide TBehavior >>> TBehaviorCategorization TClass TClassDescription TComposingDescription >>> TSortable TTranscript TTransformationCompatibility >>> > >>> > Cheers, >>> > -- Pavel >>> >>> >>> >> >> > > > -- > > > > Guille Polito > > > Research Engineer > > French National Center for Scientific Research - *http://www.cnrs.fr* > <http://www.cnrs.fr> > > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Guillermo Polito

But that's not the case. The only usage of traits in the Kernel is TBehaviour, to share some common behaviour between traits and classes. But Pablo is working on a new modular implementation of traits that would not require TBehavior, and would simplify the code of classes. On Tue, Jun 27, 2017 at 3:04 PM, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > > > 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > >> Just for curiosity: Is it a good decision? It is supposed that with >> Traits we can have less code duplication. And maybe the code duplication >> happens also in the Pharo kernel, right? >> >> Thanks for any explanation :-) >> > > You are right, it will cause more code duplicities in the kernel. On the > other hand we will be able to clean the traits implementation and make it > more modular, so the users will have more options like stateful traits, > talents etc. We needed to do a small step back to be able to move forward. > It was not an easy decision but it was planned for a long time. And in the > end, this decision was done by people who introduced traits and invested a > lot of time and effort into them. > > > Thatâs interesting. Thanks for the explanation :-) > > Juraj > > > -- Pavel > > > >> >> Cheers, >> Juraj >> >> > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> escribiÃ³: >> > >> > Hi, >> > >> > because we want to have traits only as an option where people will be >> able to choose custom traits implementation, the Pharo kernel cannot depend >> on them. For that reason we had to flatten all classes that use traits in >> the kernel packages. >> > That means that methods from system traits as TBehavior [1] were copied >> to the trait users and the traits were removed from the class definitions. >> For now these traits are still present in the image. >> > If you use own traits in your projects, this step will have no impact >> on you. Only if your project extends the system traits, you will need to >> adopt it for Pharo 7. >> > >> > [1] complete list: TApplyingOnClassSide TBehavior >> TBehaviorCategorization TClass TClassDescription TComposingDescription >> TSortable TTranscript TTransformationCompatibility >> > >> > Cheers, >> > -- Pavel >> >> >> > > -- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Tudor Girba

Great contribution! Doru > On Jun 27, 2017, at 2:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban ! > > -- www.tudorgirba.com www.feenk.com "Quality cannot be an afterthought."

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Juraj Kubelka

> El 27-06-2017, a las 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > > > 2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com <mailto:juraj.kubelka@icloud.com>>: > Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right? > > Thanks for any explanation :-) > > You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward. > It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them. Thatâs interesting. Thanks for the explanation :-) Juraj > > -- Pavel > > > > Cheers, > Juraj > > > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com <mailto:pavel.krivanek@gmail.com>> escribiÃ³: > > > > Hi, > > > > because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages. > > That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility > > > > Cheers, > > -- Pavel > > >

June 27, 2017

Re: [Pharo-dev] [ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by phil＠highoctane.be

Wow. Phil On Tue, Jun 27, 2017 at 2:56 PM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > P3 is a modern, lean and mean PostgreSQL client for Pharo. > > P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] > and later), implementing the simple query cycle. It supports plaintext and > md5 password authentication as well as SSL connections. When SQL queries > return row data, incoming data is efficiently converted to objects. > P3Client supports most common PostgreSQL types. > > With P3DatabaseDriver, an interface between Glorp, an advanced > object-relational mapper, and P3Client, most Glorp unit tests pass (the > same number as the older, proven PostgresV2 driver, that is using the > legacy 2.0 protocol). This was the initial design goal. > > More info, usage examples and code at https://github.com/svenvc/P3 > > P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. > > This is an alpha release for the brave of heart that needs more real world > testing before it is ready for general release. > > Sven > > PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser > and it was a beautiful & satisfying experience. Thank you Denis, well done > ! I also used Iceberg a second time and it starts to feel natural to me. > Thank you Nico and Esteban ! > > >

June 27, 2017

[ANN] P3, a modern, lean and mean PostgreSQL client for Pharo

by Sven Van Caekenberghe

P3 is a modern, lean and mean PostgreSQL client for Pharo. P3Client uses frontend/backend protocol 3.0 (PostgreSQL version 7.4 [2003] and later), implementing the simple query cycle. It supports plaintext and md5 password authentication as well as SSL connections. When SQL queries return row data, incoming data is efficiently converted to objects. P3Client supports most common PostgreSQL types. With P3DatabaseDriver, an interface between Glorp, an advanced object-relational mapper, and P3Client, most Glorp unit tests pass (the same number as the older, proven PostgresV2 driver, that is using the legacy 2.0 protocol). This was the initial design goal. More info, usage examples and code at https://github.com/svenvc/P3 P3 is written in pure Pharo, using a TCP network connection to PostgreSQL. This is an alpha release for the brave of heart that needs more real world testing before it is ready for general release. Sven PS: I wrote this using 64-bit Pharo 6 on macOS using the Calypso browser and it was a beautiful & satisfying experience. Thank you Denis, well done ! I also used Iceberg a second time and it starts to feel natural to me. Thank you Nico and Esteban !

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

2017-06-27 14:26 GMT+02:00 Juraj Kubelka <juraj.kubelka(a)icloud.com>: > Just for curiosity: Is it a good decision? It is supposed that with Traits > we can have less code duplication. And maybe the code duplication happens > also in the Pharo kernel, right? > > Thanks for any explanation :-) > You are right, it will cause more code duplicities in the kernel. On the other hand we will be able to clean the traits implementation and make it more modular, so the users will have more options like stateful traits, talents etc. We needed to do a small step back to be able to move forward. It was not an easy decision but it was planned for a long time. And in the end, this decision was done by people who introduced traits and invested a lot of time and effort into them. -- Pavel > > Cheers, > Juraj > > > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> > escribiÃ³: > > > > Hi, > > > > because we want to have traits only as an option where people will be > able to choose custom traits implementation, the Pharo kernel cannot depend > on them. For that reason we had to flatten all classes that use traits in > the kernel packages. > > That means that methods from system traits as TBehavior [1] were copied > to the trait users and the traits were removed from the class definitions. > For now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on > you. Only if your project extends the system traits, you will need to adopt > it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior > TBehaviorCategorization TClass TClassDescription TComposingDescription > TSortable TTranscript TTransformationCompatibility > > > > Cheers, > > -- Pavel > > >

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Pavel Krivanek

2017-06-27 14:27 GMT+02:00 Peter Uhnak <i.uhnak(a)gmail.com>: > Just so I understand... if I have extended e.g. TBehavior, I will need to > lookup all the users and copy the method everywhere? > Yes -- Pavel > > > On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote: > > Hi, > > > > because we want to have traits only as an option where people will be > able > > to choose custom traits implementation, the Pharo kernel cannot depend on > > them. For that reason we had to flatten all classes that use traits in > the > > kernel packages. > > That means that methods from system traits as TBehavior [1] were copied > to > > the trait users and the traits were removed from the class definitions. > For > > now these traits are still present in the image. > > If you use own traits in your projects, this step will have no impact on > > you. Only if your project extends the system traits, you will need to > adopt > > it for Pharo 7. > > > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization > > TClass TClassDescription TComposingDescription TSortable TTranscript > > TTransformationCompatibility > > > > Cheers, > > -- Pavel > >

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Peter Uhnak

Just so I understand... if I have extended e.g. TBehavior, I will need to lookup all the users and copy the method everywhere? On Tue, Jun 27, 2017 at 02:16:14PM +0200, Pavel Krivanek wrote: > Hi, > > because we want to have traits only as an option where people will be able > to choose custom traits implementation, the Pharo kernel cannot depend on > them. For that reason we had to flatten all classes that use traits in the > kernel packages. > That means that methods from system traits as TBehavior [1] were copied to > the trait users and the traits were removed from the class definitions. For > now these traits are still present in the image. > If you use own traits in your projects, this step will have no impact on > you. Only if your project extends the system traits, you will need to adopt > it for Pharo 7. > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization > TClass TClassDescription TComposingDescription TSortable TTranscript > TTransformationCompatibility > > Cheers, > -- Pavel

June 27, 2017

Re: [Pharo-dev] Flattened traits in Pharo 7

by Juraj Kubelka

Just for curiosity: Is it a good decision? It is supposed that with Traits we can have less code duplication. And maybe the code duplication happens also in the Pharo kernel, right? Thanks for any explanation :-) Cheers, Juraj > El 27-06-2017, a las 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> escribiÃ³: > > Hi, > > because we want to have traits only as an option where people will be able to choose custom traits implementation, the Pharo kernel cannot depend on them. For that reason we had to flatten all classes that use traits in the kernel packages. > That means that methods from system traits as TBehavior [1] were copied to the trait users and the traits were removed from the class definitions. For now these traits are still present in the image. > If you use own traits in your projects, this step will have no impact on you. Only if your project extends the system traits, you will need to adopt it for Pharo 7. > > [1] complete list: TApplyingOnClassSide TBehavior TBehaviorCategorization TClass TClassDescription TComposingDescription TSortable TTranscript TTransformationCompatibility > > Cheers, > -- Pavel

June 27, 2017