A few proposed is: additions

Hi Phil,

I apologize for taking so long to answer. I took a quick look at your
code, and I was hoping to integrate it before answering. But I haven't
done that yet, and I shouldn't delay any longer in answering.

Thank you very much for your code. One thing you made me realize is that
there is at least one implementor of #is: (CodeProvider) whose answer is
not "static". This is incompatible with your idea of caching the
protocols in the class side. But I realized that it was an improper use
of #is:. That question should be #isRefusingToAccept, with whatever
needed implementors. So, please give me a little more time to check the
system and integrate your code.

BTW, can I have your full name? Method #knownInitialsAndNames should
ideally include the name of all authors of code in the image. Anybody
else who want their initials / name in the image, please tell. Besides,
this is nice, because when the system needs your name, if your initials
are known, it tries to guess, and you can avoid typing your name all the
time.

Cheers,
Juan Vuletich

Phil (list) wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Mhhh. Been looking again at it. The problem are the references to
#ShoutEnabled and #refusingToAccept. Answers to 'is: #ShoutEnabled' and
'is: #refusingToAccept' are not static, in the sense that they depend on
the state of the instance. This would suggest implementing
#isShoutEnabled and #isRefusingToAccept. But as any object could be the
ultimate model of a text morph, (thanks to PluggableTextModel) then
#isShoutEnabled and #isRefusingToAccept would need to be implemented in
Object, answering false. But neither of this messages make real sense in
Object. Right now 'Object selectors size' is 190. This is less than in
other Squeak variants, but it is still too much. Object should only
include messages that make sense for any object. I think this needs more
thought and discussion before integration...

Regards,
Juan Vuletich

Juan Vuletich wrote:

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jun 27, 2012, at 10:17 PM, Juan Vuletich wrote:

Perfect timing :-)  I figured you either needed more time to think it through or were busy on other things so I took a shot at integrating it into the image to see what I ran into (I have a changeset that I'll finish up and publish to github tomorrow) and here's what I found:

1) As you mentioned: CodeProvider and PluggableTextModel.  For CodeProvider, isn't that just performing static tests on two symbols? If so, the approach proposed can handle that without a problem.  For PluggableTextModel, I overrode the #is: method for it and added the dynamic test before the static test. (before vs. after was just an arbitrary call on my part) thinking that this could be documented in a couple of places via method comments.  As the dynamic check is calling #is: on whatever the inst var in question happens to be, I didn't think too much of it at the time... do you anticipate this being a more common scenario going forward?

How about adding a #protocols entry of #dynamic to indicate that a particular class is performing an (at least partially) dynamic #is: check?  The result would seem to be that #protocols would still correctly identify all valid protocols, the #dynamic entry would identify cases where the determination isn't entirely static, and #is: (via the override described above) would behave identically to the current implementation.

2) Given the warnings in Object re: not adding inst vars due to VM assumptions and recent list discussions re: VM changes, I was concerned that about an issue that may or may not be valid.  Even though class inst vars weren't mentioned specifically, adding one on Object might be a bad idea as there could be unanticipated consequences (now or in the future).  The workaround I came up with was to put the class inst var in the direct subclasses of Object that implement #protocols rather than Object itself.  This required some minor logic changes (including a new method #protocolsReset that just sets the class inst var to nil) and results in some code redundancy which could possibly be (at least partially) avoided via dynamic introspection but I haven't dug too deeply into this yet.  This results in a less clean / simple implementation but was the best I could come up with given what appear to be the realities of the VM.

I was actually more concerned about second item than the first... your thoughts?

>> BTW, can I have your full name? Method #knownInitialsAndNames should ideally include the name of all authors of code in the image. Anybody else who want their initials / name in the image, please tell. Besides, this is nice, because when the system needs your name, if your initials are known, it tries to guess, and you can avoid typing your name all the time.
>>

Sure: Phil Bellalouna and my code uses pb as initials.

>> Cheers,
>> Juan Vuletich


Thanks,
Phil


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

I've just pushed out isRework.cs to https://github.com/pbella/Cuis-Experiments

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

Please take a look at my rewrite. I guess the purpose of the differences
is evident, but please ask or complain if you differ.

Cheers,
Juan Vuletich

Phil (list) wrote:
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

On Jul 5, 2012, at 7:39 AM, Juan Vuletich wrote:

> Hi Phil,
>
> Please take a look at my rewrite. I guess the purpose of the differences is evident, but please ask or complain if you differ.
>

I definitely prefer your more elegant approach so no complaints.  I did have to make a change to allProtocols (attached) to handle nil.


> Cheers,
> Juan Vuletich

Thanks,
Phil
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan,

I just wanted to touch base on some changes we discussed a while back
related to #is: / protocols.  I was wondering if this got lost in the
shuffle or if you decided against doing it?

Thanks,
Phil

On Fri, 2012-07-06 at 23:48 -0400, Phil (list) wrote:


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Hi Phil,

On 3/10/2015 2:00 AM, Phil (list) wrote:
> Juan,
>
> I just wanted to touch base on some changes we discussed a while back
> related to #is: / protocols.  I was wondering if this got lost in the
> shuffle or if you decided against doing it?
>
> Thanks,
> Phil

This was loaded as #1313 in June 2012. But the idea didn't really catch
on, and nobody worked on unifying the concept of 'protocols' all over
the system. This was needed, as the aim for Cuis is to try to be
consistent, and use few concepts system wide.

I removed it in #1629 on March 2013, as the advantages were not really
exercised, and it added complexity that didn't seem worth it.

But we can reopen discussion, if you want.

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On Tue, 2015-03-10 at 10:49 -0300, Juan Vuletich wrote:
Well that's a bummer and unfortunately I've been running with it in 4.0
since we discussed it so obviously I wasn't active in submitting
changes.  It's something I really want but if it's not something others
see the value of I won't push for it in core.  It seemed like a logical
fit for use with #is: but I can always just implement it using a
different method for my code.

> Cheers,
> Juan Vuletich



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On Tue, 2015-03-10 at 14:39 -0400, Phil (list) wrote:
One thing that would be helpful: can you recommend a way to
programmatically add a class variable to an existing class?  One thing
that I'm recalling is that if a changeset with class overrides is saved
to add them, over time this will become a maintenance chore as other
subsequent upstream changes will be lost unless I'm constantly
re-merging these changes in. (i.e. if my changeset adds a class variable
foo and the class later adds bar, my changeset will override effectively
removing bar)

> > Cheers,
> > Juan Vuletich
>



_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

On 3/11/2015 11:30 PM, Phil (list) wrote:
Not really, but you can take a look at #declare: (and senders, and
implementors of various sent messages), and experiment with that...

Cheers,
Juan Vuletich

>>> Cheers,
>>> Juan Vuletich
>
>


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org