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? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
