Grease for Squeak

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

Grease for Squeak

John McKeon
Hello Seasode-Developers
I would like your opinions on proceeding with the creation of a Grease platform for Squeak. The question arises, why not just subclass GRPharoPlatform and override the few methods that need overriding for Squeak and be done with it. Things would be much simpler than the alternative method of copying GRPharoPlatform and making it Squeak's own. This path not only requires quite a bit of class copying (mostly the codecs amd related streams), but also requires a duplication of every Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless ther is something I am missing). Not to mention the rewiring of the ConfiguationOfSeaside3 that would be necessary.
So, in light of the close relationship of Pharo to Squeak and the overwhelming amount of code reuse that it would afford, is subclassing that bad?
I look forward to your thoughts

Happy Trails
John McKeon


--
jmck.seasidehosting.st

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

Johan Brichau-2
Hi John,

This is how it has been done since years and, indeed, I do not see a downside about creating the platform class for Squeak as a subclass of the Pharo platform class.

I don’t see why there would be a need for Seaside-Squeak-* packages at this time though. The differences should still be located in the Grease layer at this time.
Over time, this may become necessary for some packages but we try to avoid this whenever possible. Of course, this requires someone to monitor the Squeak platform.

Johan

On 22 Dec 2014, at 01:46, John McKeon <[hidden email]> wrote:

Hello Seasode-Developers
I would like your opinions on proceeding with the creation of a Grease platform for Squeak. The question arises, why not just subclass GRPharoPlatform and override the few methods that need overriding for Squeak and be done with it. Things would be much simpler than the alternative method of copying GRPharoPlatform and making it Squeak's own. This path not only requires quite a bit of class copying (mostly the codecs amd related streams), but also requires a duplication of every Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless ther is something I am missing). Not to mention the rewiring of the ConfiguationOfSeaside3 that would be necessary.
So, in light of the close relationship of Pharo to Squeak and the overwhelming amount of code reuse that it would afford, is subclassing that bad?
I look forward to your thoughts

Happy Trails
John McKeon


--
jmck.seasidehosting.st
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

Tobias Pape

On 22.12.2014, at 07:19, Johan Brichau <[hidden email]> wrote:

>
> I don’t see why there would be a need for Seaside-Squeak-* packages at this time though. The differences should still be located in the Grease layer at this time.

I second that.

BEst
        -Tobias_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

Philippe Marschall
In reply to this post by John McKeon
On Mon, Dec 22, 2014 at 1:46 AM, John McKeon <[hidden email]> wrote:

> Hello Seasode-Developers
> I would like your opinions on proceeding with the creation of a Grease
> platform for Squeak. The question arises, why not just subclass
> GRPharoPlatform and override the few methods that need overriding for Squeak
> and be done with it. Things would be much simpler than the alternative
> method of copying GRPharoPlatform and making it Squeak's own. This path not
> only requires quite a bit of class copying (mostly the codecs amd related
> streams), but also requires a duplication of every Seaside-Pharo-• package
> to a Seaside-Squeak-• package as well (unless ther is something I am
> missing). Not to mention the rewiring of the ConfiguationOfSeaside3 that
> would be necessary.
> So, in light of the close relationship of Pharo to Squeak and the
> overwhelming amount of code reuse that it would afford, is subclassing that
> bad?
> I look forward to your thoughts

Whatever works best for you. It will be a bit confusing since in
Squeak you'll have Grease-Pharo-Core and Grease-Squeak-Core (I assume
the GRPharoPlatform subclass goes here) loaded. Things may get tricky
once there is a single class extension for Pharo that doesn't work for
Squeak.
In general I would recommend you to just try it out and see whether it works.

Cheers
Philippe
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

John McKeon
In reply to this post by John McKeon
Hello everyone,
If someone would give commit rights to user jmckeon I will post the updates.
Thanks

On Sun, Dec 21, 2014 at 7:46 PM, John McKeon <[hidden email]> wrote:
Hello Seasode-Developers
I would like your opinions on proceeding with the creation of a Grease platform for Squeak. The question arises, why not just subclass GRPharoPlatform and override the few methods that need overriding for Squeak and be done with it. Things would be much simpler than the alternative method of copying GRPharoPlatform and making it Squeak's own. This path not only requires quite a bit of class copying (mostly the codecs amd related streams), but also requires a duplication of every Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless ther is something I am missing). Not to mention the rewiring of the ConfiguationOfSeaside3 that would be necessary.
So, in light of the close relationship of Pharo to Squeak and the overwhelming amount of code reuse that it would afford, is subclassing that bad?
I look forward to your thoughts

Happy Trails
John McKeon


--
jmck.seasidehosting.st



--

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

Paul DeBruicker
Hi John,

I added you to the Seaside team so you should be all set.  


Thanks


Paul






John McKeon wrote
Hello everyone,
If someone would give commit rights to user jmckeon I will post the updates.
Thanks

On Sun, Dec 21, 2014 at 7:46 PM, John McKeon <[hidden email]> wrote:

> Hello Seasode-Developers
> I would like your opinions on proceeding with the creation of a Grease
> platform for Squeak. The question arises, why not just subclass
> GRPharoPlatform and override the few methods that need overriding for
> Squeak and be done with it. Things would be much simpler than the
> alternative method of copying GRPharoPlatform and making it Squeak's own.
> This path not only requires quite a bit of class copying (mostly the codecs
> amd related streams), but also requires a duplication of every
> Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless ther
> is something I am missing). Not to mention the rewiring of the
> ConfiguationOfSeaside3 that would be necessary.
> So, in light of the close relationship of Pharo to Squeak and the
> overwhelming amount of code reuse that it would afford, is subclassing that
> bad?
> I look forward to your thoughts
>
> Happy Trails
> John McKeon
>
>
> --
> jmck.seasidehosting.st
>



--
jmck.seasidehosting.st

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

John McKeon
Thanks Paul
Last night I completed posting new Grease packages as well as updates to the ConfigurationOfGrease. It appears I've made the Seaside CI job unstable?

On Sun, Mar 15, 2015 at 6:25 PM, Paul DeBruicker <[hidden email]> wrote:
Hi John,

I added you to the Seaside team so you should be all set.


Thanks


Paul







John McKeon wrote
> Hello everyone,
> If someone would give commit rights to user jmckeon I will post the
> updates.
> Thanks
>
> On Sun, Dec 21, 2014 at 7:46 PM, John McKeon &lt;

> p3anoman@

> &gt; wrote:
>
>> Hello Seasode-Developers
>> I would like your opinions on proceeding with the creation of a Grease
>> platform for Squeak. The question arises, why not just subclass
>> GRPharoPlatform and override the few methods that need overriding for
>> Squeak and be done with it. Things would be much simpler than the
>> alternative method of copying GRPharoPlatform and making it Squeak's own.
>> This path not only requires quite a bit of class copying (mostly the
>> codecs
>> amd related streams), but also requires a duplication of every
>> Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless
>> ther
>> is something I am missing). Not to mention the rewiring of the
>> ConfiguationOfSeaside3 that would be necessary.
>> So, in light of the close relationship of Pharo to Squeak and the
>> overwhelming amount of code reuse that it would afford, is subclassing
>> that
>> bad?
>> I look forward to your thoughts
>>
>> Happy Trails
>> John McKeon
>>
>>
>> --
>> jmck.seasidehosting.st
>>
>
>
>
> --
> jmck.seasidehosting.st
>
> _______________________________________________
> seaside-dev mailing list

> seaside-dev@.squeakfoundation

> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev





--
View this message in context: http://forum.world.st/Grease-for-Squeak-tp4796637p4812136.html
Sent from the Seaside Development mailing list archive at Nabble.com.
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev



--

_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: Grease for Squeak

Johan Brichau-2
Not at all. The Seaside built is unstable for Pharo 4 only, which was added recently to the build job.

I updated the github project with your changes and seems like all is good: https://travis-ci.org/GsDevKit/Grease/builds/55359027

Johan

On 20 Mar 2015, at 14:03, John McKeon <[hidden email]> wrote:

Thanks Paul
Last night I completed posting new Grease packages as well as updates to the ConfigurationOfGrease. It appears I've made the Seaside CI job unstable?

On Sun, Mar 15, 2015 at 6:25 PM, Paul DeBruicker <[hidden email]> wrote:
Hi John,

I added you to the Seaside team so you should be all set.


Thanks


Paul







John McKeon wrote
> Hello everyone,
> If someone would give commit rights to user jmckeon I will post the
> updates.
> Thanks
>
> On Sun, Dec 21, 2014 at 7:46 PM, John McKeon &lt;

> p3anoman@

> &gt; wrote:
>
>> Hello Seasode-Developers
>> I would like your opinions on proceeding with the creation of a Grease
>> platform for Squeak. The question arises, why not just subclass
>> GRPharoPlatform and override the few methods that need overriding for
>> Squeak and be done with it. Things would be much simpler than the
>> alternative method of copying GRPharoPlatform and making it Squeak's own.
>> This path not only requires quite a bit of class copying (mostly the
>> codecs
>> amd related streams), but also requires a duplication of every
>> Seaside-Pharo-• package to a Seaside-Squeak-• package as well (unless
>> ther
>> is something I am missing). Not to mention the rewiring of the
>> ConfiguationOfSeaside3 that would be necessary.
>> So, in light of the close relationship of Pharo to Squeak and the
>> overwhelming amount of code reuse that it would afford, is subclassing
>> that
>> bad?
>> I look forward to your thoughts
>>
>> Happy Trails
>> John McKeon
>>
>>
>> --
>> jmck.seasidehosting.st
>>
>
>
>
> --
> jmck.seasidehosting.st
>
> _______________________________________________
> seaside-dev mailing list

> seaside-dev@.squeakfoundation

> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev





--
View this message in context: http://forum.world.st/Grease-for-Squeak-tp4796637p4812136.html
Sent from the Seaside Development mailing list archive at Nabble.com.
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev



--
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev