--- Jesse Butler <Jesse.Butler [at] Sun.COM> wrote: > Jerry Hedden wrote: >> Does it have to be? For example, according to CPANTS there are no >> CPAN modules that have 'threads' as a requirement other than >> 'thread::shared', 'Thread::Suspend' and 'Thread::Cancel', and I >> know they won't break. > > John Peacock remarked: >> The world isn't CPAN; there may be lots of private code which uses >> 'threads' which you won't ever find out about. > > Of course. I only used CPAN modules as an example. > >> More to the point, however, is what does it do _now_, i.e. can you >> currently stringify a thread object at all? If that concept isn't >> available now, this has nothing do to with 'backwards compatibility' >> at all, since you are introducing new behavior... > > Currently, stringifying a threads object results in a string like: > threads=SCALAR(0x100326a4) > just as any object would stringify. Not entirely useful other than > it being a unique string, and telling you it was a threads object. > As such, I would tend to classify it as 'new behavior'. > > Yves (demerphq) commented: >> That's the problem with having default stringification behaviour. >> Unless you explicitly document the stringification behaviour as >> being open to change people are allowed to assume it wont and use >> the default behaviour. > > Agreed, but does that mean this is really such a big deal that a > slight potential for imcompatibility is grounds for barring any > improvements?
No, I would think not. It would be one thing to address serious compatibility issues, but if the only requirement is to not alter useless behaviour - well, then it'll stay useless. It is key that this is new functionality. You are not altering an existing interface, I cannot foresee this breaking anything. I think this is a safe move, and ultimately very useful. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
