KCP 64-90 - comments, questions and approvals

Stephane Ducasse ducasse at iam.unibe.ch
Thu Jun 26 19:34:50 UTC 2003


> Doug, KCP doesn't show up in BFAV yet, hence this heads up. This
> approves almost all the outstanding KCP stuff.
>
> To business - I really like the way the new deprecation system works
> out. People deprecating all sorts of protocols should really be using
> this. Of course for every deprecation we do, eventually, we'll have to
> remove the deprecated code - maybe we should do this at the beginning 
> of
> each alpha?
>
> A small deployment question - I got a deprecation wb at 84, proceeded,
> and all was fine. This cause me to think something that somewhat 
> related
> to the above - maybe we should have a preference to decide whether
> deprecation should be active or not, and set it to false when we want 
> it
> to work quietly? this could be used to solve this small annoyance, but
> even better, we could set to off in released images, and to on in
> alpha/beta/gamma images. This would hide ugliness from end users, but
> not from the rest of us.

Daniel normally this should not happen with the stuff inside the image.
For the one you mention I could not do it otherwise because I could not
change the bytecode of the method that is loading the change that 
modifies
itself ;). The change modifies the loading while loading it :).

>
> What do you think?

I would not bother. Because the deprecated showing up will push people
to change. Then if you get fed up and need to go fast for a hack. People
are good enough to change the method deprecated.

So I would not do anything because only expert need that and it will 
only take them 1 min
to fix it if they need ti.

>
> BTW, why did you add the *Deprecated methods?
>
> A note about my review - I didn't check all the code, I only understood
> the design idea and sampled the implementation to get a taste. IOW, I
> think we have this process pretty well optimized, and it's not taking 
> me
> a long time. So we can run with this as quick as the KCP team wants, 
> and
> I wont mind doing the approvals more frequently, if you tell me when 
> you
> have a logical part completed.

This is perfect for us.
We try to work by logical chunk. I can tell you that nathanael will 
start to
reimplement traits from scratch and fix the kernel when needed. In the 
meantime
I will continue to produce at least two  changesets per week.
Roel will work on the changes notification he mentioned.

Noury is starting to participate but I do not know his agenda.

> One place where I think things should be done differently (we talked
> about this before -)
> 64. The way HTTPSocket is changed makes the dependency on GifReadWriter
> dynamic/hidden from analysis, but the methods are still ineffective 
> when
> the media handling classes are missing. I think those are exactly the
> case where a class extension would be better - if the media code is
> removed, so should the methods that depend on it. I'm less sure about
> Form, maybe its media sampling code should be extracted to some
> ImageReaderWriter too?

I agree with you but I have no time to use DVS/Monticello now. If you 
have the
time please do it if this is the time to do it.

> Everything else, that is, 67, 68, 69, 70, 71, 76, 78, 83, 84, 85, 87,
> 88, 90 - approved.

Cool. Now we have nothing left except working again to produce others.

>
>
Hi all

please play with the system because we move the changeset singleton to 
the place
where is should be ie changeset class so we may have lost some calls. 
Noury already reviewed
that carefully but who knows. :)




More information about the Squeak-dev mailing list