Dear Pharo users and developers, Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. Happy reading! Ciao, Koen

It sounds promising. I want it now ;-) Noury On Mar 18 2024, at 6:51 pm, Koen De Hondt <koen@all-objects-all-the-time.st> wrote: > Dear Pharo users and developers, > > Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. > If you liked it, I invite you to read the next post (https://all-objects-all-the-time.st/#/blog/posts/7). It describes the Classification Model, which is the foundation of Atlas. > > Happy reading! > > Ciao, > Koen >

Hi Koen - is there any particular place you would like us to feedback on the posts? Is here useful, or some other location? I like the concepts you are introducing (I need to take to read your PHD - so good to have the link in there) - but the devil is in the detail of course. If I have understood correctly - the idea of computed classifications give rise to the flexibility we all crave? So in my previous comment - when designing a new class and trying to work out its protocol, in particular how to instantiate it vs. update it - its very inconvenient to have to flip between class and instance method definitions - a much flatter view of a Class has both instance AND class methods that I can see together is more efficient to work with in that initial design phase vs later when stabilised the more traditional - a Class name has Class and Instance definition, a Class definition has class methods, an Instance definition has instance methods (apologies if terminology isn't quite right - typing this in a hurry on a break). But does the classification model handle the above? To flatten instance and class methods into a single sorted list (discriminated in some manner - like one being bold or having some prefix) and also allowing you to add to add new items to that list and provide that discrimination sounds like it might not fit that classification model? Or maybe it does? I guess we do currently allow methods to have categories and we can view multiple categories in a list. I guess I'm curious how it hangs together to model non-trivial examples? And maybe this is the next blog post? Thanks for surfacing the ideas. Tim On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote: > Dear Pharo users and developers, > > Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. > If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. > > Happy reading! > > Ciao, > Koen

Hi Tim, This is a good place to discuss. I did not add comment functionality to my blog because I do not want people to spam the site with stuff that is not related to the content, and I do not want to moderate the comments. Sending me messages is fine too, but here everyone can read along. You have understood correctly, but I consider it a virtual classification rather than a computed classification because the classification does not depend on user input. Atlas has an “AllMethodsClassification” that holds items for all methods of a class. It is used for instance methods and class methods, depending on the “source” of the classification, either a class or a metaclass. Suppose you implement a new classification, let’s say “AllInstanceMethodsAndClassMethodsClassification”, that holds items for all instance methods and class methods of a class, then you are all set. All items and classifications have a display name, which is shown in the UI. However, the display name depends on the context. If it is clear from the context that #example is a class method, then displaying “example” is fine. However, when the context is more general, like any manual classification that can hold anything, displaying “My class>>#example” would be more appropriate. So just implementing a new kind of classification would not be enough for your use case. Therefore I would also implement a dedicated view on that classification so that the list in the view can indicate whether a method is an instance or a class method, together with the protocol it belongs to. An alternative to what you propose, and a better solution in my opinion, is to have two views side by side, so that instance and class methods are not mixed. That simplifies the implementation, certainly because Atlas has both views, and composing your own browser is possible. That is certainly a topic for a future post. Thank you for your questions. I welcome all feedback, as it will shape Atlas. Ciao, Koen > On 19 Mar 2024, at 17:30, Tim Mackinnon <tim@testit.works> wrote: > > Hi Koen - is there any particular place you would like us to feedback on the posts? Is here useful, or some other location? > > I like the concepts you are introducing (I need to take to read your PHD - so good to have the link in there) - but the devil is in the detail of course. > > If I have understood correctly - the idea of computed classifications give rise to the flexibility we all crave? So in my previous comment - when designing a new class and trying to work out its protocol, in particular how to instantiate it vs. update it - its very inconvenient to have to flip between class and instance method definitions - a much flatter view of a Class has both instance AND class methods that I can see together is more efficient to work with in that initial design phase vs later when stabilised the more traditional - a Class name has Class and Instance definition, a Class definition has class methods, an Instance definition has instance methods (apologies if terminology isn't quite right - typing this in a hurry on a break). > > But does the classification model handle the above? To flatten instance and class methods into a single sorted list (discriminated in some manner - like one being bold or having some prefix) and also allowing you to add to add new items to that list and provide that discrimination sounds like it might not fit that classification model? Or maybe it does? I guess we do currently allow methods to have categories and we can view multiple categories in a list. I guess I'm curious how it hangs together to model non-trivial examples? And maybe this is the next blog post? > > Thanks for surfacing the ideas. > > Tim > > On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote: >> Dear Pharo users and developers, >> >> Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. >> If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. >> >> Happy reading! >> >> Ciao, >> Koen

By the way - it's a shame there is no rss feed for you blog as I like to use a feed reader on my phone to keep up with such things. Not sure what you are using, but if you could enable it, that would be coo. Tim On Tue, 19 Mar 2024, at 4:30 PM, Tim Mackinnon wrote: > Hi Koen - is there any particular place you would like us to feedback on the posts? Is here useful, or some other location? > > I like the concepts you are introducing (I need to take to read your PHD - so good to have the link in there) - but the devil is in the detail of course. > > If I have understood correctly - the idea of computed classifications give rise to the flexibility we all crave? So in my previous comment - when designing a new class and trying to work out its protocol, in particular how to instantiate it vs. update it - its very inconvenient to have to flip between class and instance method definitions - a much flatter view of a Class has both instance AND class methods that I can see together is more efficient to work with in that initial design phase vs later when stabilised the more traditional - a Class name has Class and Instance definition, a Class definition has class methods, an Instance definition has instance methods (apologies if terminology isn't quite right - typing this in a hurry on a break). > > But does the classification model handle the above? To flatten instance and class methods into a single sorted list (discriminated in some manner - like one being bold or having some prefix) and also allowing you to add to add new items to that list and provide that discrimination sounds like it might not fit that classification model? Or maybe it does? I guess we do currently allow methods to have categories and we can view multiple categories in a list. I guess I'm curious how it hangs together to model non-trivial examples? And maybe this is the next blog post? > > Thanks for surfacing the ideas. > > Tim > > On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote: >> Dear Pharo users and developers, >> >> Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. >> If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. >> >> Happy reading! >> >> Ciao, >> Koen >