Re^5: Are lvalue methods (as properties) a good idea?

The main reason for not putting it on CPAN is that I don't want to have to try and support other people's favourite method making features. I've been meaning to try get it into the one of the other packages but I've been away from home for a while and changing jobs etc. I might publish it as a proof of concept and invite others to steal any ideas that they like.

Comment on Re^5: Are lvalue methods (as properties) a good idea?

Replies are listed 'Best First'.
Re^6: Are lvalue methods (as properties) a good idea? by Aristotle (Chancellor) on Jan 18, 2005 at 19:39 UTC
I can see that. How about you put it on CPAN as a developer release and never pull off the tag? Others might be more motivated to steal ideas if they have a working model. Makeshifts last the longest.	[reply]
Re^7: Are lvalue methods (as properties) a good idea? by fergal (Chaplain) on Jan 18, 2005 at 21:00 UTC
This was one of the reasonAlong time back on the module-authors list I suggested there should be an `ID` namespace on CPAN so that I could put this in `ID::FDALY::MethodMaker` [download] along with other interesting/useful stuff that I don't want to keep to myself but I also don't want to make the effort and turn into a fully documented and supported module. A kind of semi-private namespace. It was not well received.	[reply] [d/l] [select]
Re^8: Are lvalue methods (as properties) a good idea? by Aristotle (Chancellor) on Jan 18, 2005 at 21:13 UTC
And I was one of those who argued against that. `:-)` But maybe we should have a `BlueSky::` TLNS… Makeshifts last the longest.	[reply]