Administrator
|
Below is a blog post and my reply... If anyone has anything to add, here's the link...
https://schrievkrom.wordpress.com/2012/09/06/working-with-pharo-1-42-0/ Thanks for the great feedback! This is gold for the Pharo dev community. I encourage you to bring this feedback to the dev list, or – even better – create issues, or (best option) take on a few so we can integrate them!! A few comments/questions: * multiple selection in 1.4 – consider the browser in 1.4 to be legacy. Nautilus will be the future browser in Pharo, and it will have multiple selection * accessor creation – will you describe what steps you took (e.g. manual creation, context menu (there are two possiblities here), etc)? If you illustrate your ideal behavior, I will create an issue and push to include it in Nautilus… * Settings – I find this one *really* interesting. Will you highlight the key differences to VA? Maybe we can improve the framework in Pharo, or at minimum create a UI that makes things simpler and more straightforward for you Re Nautilus: it is not production-ready, which is why it was not included in Pharo 1.4, but it is under heavy development by a great developer, Benjamin VanRyseghem. He is very open to this type of feedback. Specifically, I couldn’t agree more about the buttons!!! After months of using Nautilus, I /still/ have no idea whether I’m on the class or instance side.
Cheers,
Sean |
On Thu, Sep 6, 2012 at 8:30 AM, Sean P. DeNigris <[hidden email]> wrote:
> Below is a blog post and my reply... If anyone has anything to add, here's > the link... > https://schrievkrom.wordpress.com/2012/09/06/working-with-pharo-1-42-0/ ... >> * creating accessor methods for instance attributes is not speedy and >> takes too much clicks >> >> * then I looked for a setting framework and I was really surprised to see, >> how difficult it was – or at least the documentation I read about it. >> After working with the setting framework of VASmalltalk I would prefer the >> simple approach than a perhaps even more powerful approach. >> ... > * accessor creation – will you describe what steps you took (e.g. manual > creation, context menu (there are two possiblities here), etc)? If you > illustrate your ideal behavior, I will create an issue and push to include > it in Nautilus… I haven't worked with the framework in VA, and personally, don't like frameworks to create accessor methods. However, just yesterday, I really wished that the debugger had a button when enountering an unknown method called 'create accessor' or something similar - if the method looks like an accessor method for a variable that doesn't have one, offer up the option of letting the runner (coder) just create the simplest flavor right there in the debugger. It would show up right next to the Create button at the same time. My favorite method of coding, in any case... -Chris |
Administrator
|
Well, we're almost there... if you send a unary or binary message with the same name as an inst var, and click "create " from the debugger, you get an accessor template... The only problem is that is has "self shouldBeImplemented." added to it, which is not even highlighted for deletion. I've wondered for a while what the purpose of this is... Unless someone speaks up convincingly for its usefulness, I say we remove it and start with a complete and valid accessor as the template... Cheers, Sean
Cheers,
Sean |
If you want those kind of niceties in the debugger/browser look at how Dolphin Smalltalk does it.
On MNU's you can implement methods in the class of any of the parents of the receiver object. Or even implement it while in the method browser. The development experience is so streamlined that it flows naturally. Regards, -- Esteban |
In reply to this post by Sean P. DeNigris
Just some additional remarks about the setting framework and how VA has
it since its latest release. Due to its source code management (ENVY) each application has its own configuration section in a simple ascii based *.ini file. Therefore each application has a text section like [name of application] key = value ... The developer just write 3 methods on the class side of its application class, which more or less do something: one method defines all possible entries expected in the text files and what type it has one method defines current AND default values for each setting one method defines how to transfer the values to your application. That's pretty simple - but also limited - and you copy the implementation of these three methods from another application, change them according to your needs and that's it. The documentation describing the Pharo settings framework is 20 pages long and offers many more features - I actually do not need. And I do not need a GUI to edit my setting values - but for others this might be useful. The documentation is not straight forward - three or four pages with introductions. And even now I do not know how the settings are stored outside the system. But as I said before - I have not done much work with Squeak/Pharo yet - and this only reflects my early impressions when working with this system. And I even do not know, if Settings is part of Pharo 1.4 or Pharo 2.0. Just to give you an overview of my ideas here. and another point I want to say about using the system: Working with VASmalltalk/ENVY the methods called after starting, resuming, loading, unloading (and various other events) to each class/application are well documented. I do not find documents/informations about this in Pharo/Squeak and this is a very important information when initializing an application. Marten Feldtmann Am 06.09.2012 17:30, schrieb Sean P. DeNigris: > * Settings – I find this one *really* interesting. Will you highlight the > key differences to VA? Maybe we can improve the framework in Pharo, or at > minimum create a UI that makes things simpler and more straightforward for > you marten.vcf (226 bytes) Download Attachment |
In reply to this post by Sean P. DeNigris
Another hint here: I like the refactoring browser's way: multi-select
items in the list of attributes and default accessors are created - no need to edit the code here. I am in the browser, already looking at this class - and then I change the code in the browser. Marten Am 06.09.2012 17:30, schrieb Sean P. DeNigris: >> >> * creating accessor methods for instance attributes is not speedy and >> takes too much clicks >> marten.vcf (226 bytes) Download Attachment |
Free forum by Nabble | Edit this page |