Smalltalk › Squeak › Squeak - Dev

Last minute change: Object>>is:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Andreas.Raab

Last minute change: Object>>is:

Folks -

I've been thinking about this for a while now and it seems to me that
there's little harm done if we implement Object>>is: to just return
false at this point. This doesn't say anything about whether we should
use it or how we should use it but it seems to me that it would be a
useful compatibility method to have, just in case someone wants to use
it in an external package.

Any strong opposition to that change?

Cheers,
- Andreas

Igor Stasenko

Re: Last minute change: Object>>is:

On 7 April 2010 19:38, Andreas Raab <[hidden email]> wrote:

> Folks -
>
> I've been thinking about this for a while now and it seems to me that
> there's little harm done if we implement Object>>is: to just return false at
> this point. This doesn't say anything about whether we should use it or how
> we should use it but it seems to me that it would be a useful compatibility
> method to have, just in case someone wants to use it in an external package.
>
> Any strong opposition to that change?
>

Not me :)

> Cheers,
> - Andreas
>
>

--
Best regards,
Igor Stasenko AKA sig.

Colin Putney

Re: Last minute change: Object>>is:

In reply to this post by Andreas.Raab

On 2010-04-07, at 9:38 AM, Andreas Raab wrote:

> Folks -
>
> I've been thinking about this for a while now and it seems to me that there's little harm done if we implement Object>>is: to just return false at this point. This doesn't say anything about whether we should use it or how we should use it but it seems to me that it would be a useful compatibility method to have, just in case someone wants to use it in an external package.
>
> Any strong opposition to that change?

Yes. I think #is: is a bad idea all around, and we shouldn't be encouraging it.

Colin

Andreas.Raab

Re: Last minute change: Object>>is:

On 4/8/2010 9:22 PM, Colin Putney wrote:

>
> On 2010-04-07, at 9:38 AM, Andreas Raab wrote:
>
>> Folks -
>>
>> I've been thinking about this for a while now and it seems to me that there's little harm done if we implement Object>>is: to just return false at this point. This doesn't say anything about whether we should use it or how we should use it but it seems to me that it would be a useful compatibility method to have, just in case someone wants to use it in an external package.
>>
>> Any strong opposition to that change?
>
> Yes. I think #is: is a bad idea all around, and we shouldn't be encouraging it.

Even if used purely as a measure of compatibility?
What I was thinking about was an implementation that just said:

Object>>is: aSymbol
"For compatibility only"
^false

Cheers,
- Andreas

Colin Putney

Re: Last minute change: Object>>is:

On 2010-04-09, at 4:05 PM, Andreas Raab wrote:

> On 4/8/2010 9:22 PM, Colin Putney wrote:
>>
>> On 2010-04-07, at 9:38 AM, Andreas Raab wrote:
>>
>>> Folks -
>>>
>>> I've been thinking about this for a while now and it seems to me that there's little harm done if we implement Object>>is: to just return false at this point. This doesn't say anything about whether we should use it or how we should use it but it seems to me that it would be a useful compatibility method to have, just in case someone wants to use it in an external package.
>>>
>>> Any strong opposition to that change?
>>
>> Yes. I think #is: is a bad idea all around, and we shouldn't be encouraging it.
>
> Even if used purely as a measure of compatibility?
> What I was thinking about was an implementation that just said:
>
> Object>>is: aSymbol
> "For compatibility only"
> ^false

Well, compatibility is good, so I'd be less opposed to a single "strictly for compatibility" method. But is there really a need for this? Are there packages that rely in this? If there aren't, why invite them to do so?

Colin

Andreas.Raab

Re: Last minute change: Object>>is:

On 4/9/2010 9:58 PM, Colin Putney wrote:
>
> Well, compatibility is good, so I'd be less opposed to a single "strictly for compatibility" method. But is there really a need for this? Are there packages that rely in this? If there aren't, why invite them to do so?

Fair enough. I was thinking the issue would be less controversial. We'll
leave it for now and see what happens.

Cheers,
- Andreas