[Cuis-dev] reflection in Cuis

Hernán Wilkinson hernan.wilkinson at 10pines.com
Fri Jun 14 13:57:58 PDT 2024


On Fri, Jun 14, 2024 at 5:25 PM Mark Volkmann <r.mark.volkmann at gmail.com>
wrote:

> That was very helpful! The attached screenshot shows the result of
> following your advice.
> I can enter the following in a Workspace to get a list of all the
> installed packages:
>
> CodePackageList new packages
>

Great!
You also have "CodePackage installedPackages", in fact
CodePackageList>>#packages does that :-)


> My remaining misunderstanding is what tab completion does. When I enter "Smalltalk
> pac" and press tab, I expect to see a list of messages that I can send to
> the Smalltalk global object.
>

Currently, if there is no message that Smalltalk responds that starts with
pac, it will show you all the selectors that start with pac because there
is no warranty that you do not want to send that message to that object
even though it does not understand it. But, in the case of Smalltalk
because we know its type, it shows the selectors in blue, to let you know
that is not a message that will respond unless you implement it.


> Are you saying that it considers every method of every class and not
> just the ones that apply to the Smalltalk object?
>

All the selectors, there is a cache for that in the autocompletion.


> Is that why it shows me the packages method that only applies to the
> CodePackageList?
>

Yes.
But again, this is like that because we know the type of the receiver.
If we do not know the type of the receiver, it will always show you the
selectors that match the prefix



> On Fri, Jun 14, 2024 at 1:52 PM Hernán Wilkinson <
> hernan.wilkinson at 10pines.com> wrote:
>
>> yes, there are ways because if a tool (that is an object) can show you
>> that, it means that you can get the same info by finding the right message
>> and the right object :-)
>> The corollary is: if I can see it in a tool (window/morph/etc) then I can
>> do it by sending messages that already exist.
>>
>> One of the most important skills in Smalltalk is to learn how to find
>> things... for example you could start looking for messages that include the
>> packages word in it.
>> If you look for implementors of #packages you will find the answer! That
>> was easy :-)
>>
>> Another way to do it is to use the halos of a tool. Open the "Installed
>> Packages" windows, cmd+right click on it, click the orange halo, select the
>> "Inspect morph" option. Doing so you are going from a visual object to a
>> "model" object, to what that visual object is showing you. From there you
>> can navigate to find what you are looking for. For example select self in
>> the inspector, then look for reference of the class cmd+N, you will see how
>> that window is opened and that CodePackageList represent the list of
>> packages, look in that class how it is initialized, you will see it send
>> the message "updatePackageList" to self, look how it is implemented and you
>> will see how it looks for installed packages....
>> Going from visual objects to non visual ones is a really powerful tool.
>>
>> I hope it helped!
>>
>> Hernan.
>>
>>
>> On Fri, Jun 14, 2024 at 3:15 PM Mark Volkmann <r.mark.volkmann at gmail.com>
>> wrote:
>>
>>> Is there a way to find these things?
>>>
>>> - all installed packages
>>> - all class categories
>>> - all classes in a given class category
>>> - all message categories used by a given class
>>> - the source code for a given method as a string or tree of AST nodes
>>>
>>> On Fri, Jun 14, 2024 at 12:48 PM Hernán Wilkinson <
>>> hernan.wilkinson at 10pines.com> wrote:
>>>
>>>> well, they are all kind of Collection :-) and if all you need is what
>>>> Collection defines as protocol is good enough. ... that is the whole idea
>>>> behind polymorphism. That does not mean that maybe returning an Array
>>>> instead of a Set is better in some message, but we should see case by case,
>>>> how it is used that message, etc.
>>>>
>>>>
>>>> On Fri, Jun 14, 2024 at 2:32 PM Mark Volkmann via Cuis-dev <
>>>> cuis-dev at lists.cuis.st> wrote:
>>>>
>>>>> I've learned how to discover lots of things using reflection, but not
>>>>> the following. Are there methods that return these?
>>>>>
>>>>> - all installed packages
>>>>> - all class categories
>>>>> - all classes in a given class category
>>>>> - all message categories used by a given class
>>>>> - the source code for a given method as a string or tree of AST nodes
>>>>>
>>>>> There seems to be some inconsistencies in the kind of object returned
>>>>> by the reflection methods. I've encountered at least these so far: Array,
>>>>> Set, IdentitySet, and OrderCollection. I understand the distinction between
>>>>> these collection types, but it's not clear why the reflection methods don't
>>>>> all return the same kind of collection.
>>>>>
>>>>> --
>>>>> R. Mark Volkmann
>>>>> Object Computing, Inc.
>>>>> --
>>>>> Cuis-dev mailing list
>>>>> Cuis-dev at lists.cuis.st
>>>>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>>>> *Phone: +54-011*-4893-2057
>>>> *Twitter: @HernanWilkinson*
>>>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>>>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>>>
>>>
>>>
>>> --
>>> R. Mark Volkmann
>>> Object Computing, Inc.
>>>
>>
>>
>> --
>>
>> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
>> *Phone: +54-011*-4893-2057
>> *Twitter: @HernanWilkinson*
>> *site: http://www.10Pines.com <http://www.10pines.com/>*
>> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>>
>
>
> --
> R. Mark Volkmann
> Object Computing, Inc.
>


-- 

*Hernán WilkinsonAgile Software Development, Teaching & Coaching*
*Phone: +54-011*-4893-2057
*Twitter: @HernanWilkinson*
*site: http://www.10Pines.com <http://www.10pines.com/>*
Address: Alem 896, Floor 6, Buenos Aires, Argentina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240614/7a002a53/attachment-0001.htm>


More information about the Cuis-dev mailing list