ZnUrl>>#= - Why Require Same Classes?

= anObject
        ^ self class == anObject class
        ...

Most of the time, I've seen a test for #species, not class. This matters because I have a custom ZnUrl subclass that I'd like to be equal to a ZnUrl pointing to the same place.

While we're on the subject, I'm not an expert on hashing, but isn't it a problem that ZnUrl>>#hash refers to #segment, which is not immutable?

> On 23 Mar 2016, at 15:37, Sean P. DeNigris <[hidden email]> wrote:
>
> = anObject
> ^ self class == anObject class
> ...
>
> Most of the time, I've seen a test for #species, not class. This matters
> because I have a custom ZnUrl subclass that I'd like to be equal to a ZnUrl
> pointing to the same place.

Yes, that might be better.

> While we're on the subject, I'm not an expert on hashing, but isn't it a
> problem that ZnUrl>>#hash refers to #segment, which is not immutable?

I don't think the mutability is a problem (collection's hash is similar), but apart from that, the hash implementation looks a bit weird (too simple).

I am curious though why you subclasses ZnUrl. If you did not add structure but only behaviour you could have added some extension methods.

> -----
> Cheers,
> Sean
> --
> View this message in context: http://forum.world.st/ZnUrl-Why-Require-Same-Classes-tp4886102.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>

Sven Van Caekenberghe-2 wrote

I don't think the mutability is a problem

I thought it was a no-no for an object's hash to ever change, which it would if the path changed, no?

Sven Van Caekenberghe-2 wrote

I am curious though why you subclasses ZnUrl. If you did not add structure but only behaviour you could have added some extension methods.

I implemented a ProtectedUrl, which carries around the additional information it needs (in this case an authenticated client) to be accessed.