A mathematician confided
That the möbius band is one sided.
You'll have quite a laugh
If you cut one in half,
'Cause it stays in one piece when divided.
I had an idea for a joke module, that provides möbius objects: inside out objects that are also not inside-out. However, thinking more about it, I can see that this could have practical uses.
Imagine the scenario of refactoring in-house modules for inside outedness. The modules themselves could be refactored to use Class::Std, Object::InsideOut, Class::InsideOut or whatever, but lots of existing legacy code could break if it is relying on de-encapsulation ->{foo} syntax.
Möbius objects could provide a migration path allowing the legacy code to still work, albeit generating warnings whenever encapsulation is violated, but still working.
Inside out objects tend to be implemented as a blessed scalarref, using the address or some other unique low level property (their values are not actually used). The möbius object could still use this address, but be a blessed, tied hashref or arrayref. The tie mechanism will intercept any attempts to access attributes directly, and will do the right thing, generating warnings as necessary.
What do others think? Is this idea worth pursuing? Or should it retain "joke module" status?
--
Oh Lord, wont you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, wont you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
You've just described what jdhedden dubbed "foreign inheritance". Both Class::InsideOut and Object::InsideOut already support this, though in slightly different ways. The former offers it directly; the latter uses a delegation pattern for a more generalized approach. Docs for both give examples. And neither uses tie.
I've written File::Marker to go along with the inside-out tutorial I'm giving next week at Perl Seminar NY. It gives a very simple example of using the inside-out technique to extend IO::File.
Here's a couple threads on the topic as well
- How to use Inheritance with Inside-Out Classes and Hash Based Classes
- Inside-out objects inheriting from hash-based classes
-xdg
Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.
Every search result that ISN'T valuable wastes time and money for people actually trying to get WORK done with the language, which is the only point of a programming language.
Go and play games at home, but don't ruin other people's lives. Go use LOGO if you want to play childish games.
We have an Acme namespace, so joke modules don't clutter other namespaces.
Furthermore, if you don't have anything nice to say....
It's not what you look like, when you're doin' what youre doin'.
It's what youre doin' when youre doin' what you look like youre doin'!
- Charles Wright & the Watts 103rd Street Rhythm Band
Work is not the only point of any programming language. Fun, hobbies and humor are all legit too.
Isn't there enough pointless modules to wade through on CPAN already, without cluttering the namespace even more?
Nah. Bring em on! Besides he explained how in fact this wouldn't be a pointless module.
___________
Eric Hodges
And then I have to clean up the code broken by people who take that approach to their professional life. No thanks!
I'm sick of it! Be a professional adult, or be silent! Don't interfere with real people if you're going to be a child!
So don't take that approach to your professional life. I fail to see the problem. Many people enjoy coding for purposes other than work, and CPAN is a repository even for them.
The fact that these "for fun" modules exist doesn't mean they should be used in professional settings. But having professional standards where necessary shouldn't mean "all coding should be done professionally, no fun allowed, ever".
That makes no sense. As a professional coder you should be happy there are less experienced, skilled and knowledgable programmers out there. It helps justify your pay and keeps you in a job and makes you look good.
Blessed be the incompetents because while they are around the rest of us look better.
$world=~s/war/peace/g
Blessed be the incompetents because while they are around the rest of us look better.
Thank you so much, and on behalf of all my fellow incompetents I gratefully accept your blessings :)
You have a point. OTOH, some of my most treasured discoveries were made while I was looking for something else - new words, new ideas, things that jarred me out of my mental ruts - they've all been useful, even when I found them accidentally as I scrummaged around for something...
I disagree. The point of a programming language is to program - and the motivations for that are myriad. Accomplishing work is one of them, certainly - and to many people, that is the only point of programming. It's just a job. You do your job, get your pay, and do something fun on weekends, like watch television or participate in the running of the bulls or something.
Other people love to program for the joy of making something - much like some people build models, or lay out their own gardens, or put together a radio. To many people, programming is fun - a hobby, an avocation, the reason they hold a boring job - it permits them to program in their spare time.
I have no solid facts to back up my belief, but I suspect that a huge number of Perl modules on CPAN were made by people, simply for the love of making a fine tool. I'm not talking about ACME::Bleach, but useful, practical modules that are used in serious applications - by professional programmers. Whatever their motivation, writers of Perl modules weren't doing it for the money. To them, it wasn't WORK, it was PLAY.
If you find CPAN so useless, you are free to write whatever modules you need. Apparently, despite the frivolous modules and the difficulty in finding ones you need, you still find CPAN less trouble than rolling your own. But the reason those modules even exist, is that many programmers - professional and amateur - enjoy programming for its own sake, and the modules are a result of their PLAYING.
Finally, try to lighten up. Learn to love programming, or find a job you love. Life's too short to be all crabby about fun stuff.
It sounds valuable to me. I like the idea of warning on dubious constructs, even if CPAN://UNIVERSAL::isa and CPAN://UNIVERSAL::can demonstrate how difficult it can be.
I think you should consider the possibility of extending your mobius module into a klein bottle module. I'm not sure if this 3d functionality should be rolled into your initial work or outside it -- perhaps there is no difference.
Rob
It takes 2 dimensions minimum in order to have an outside and an inside - hence möbius. If you can think of an analogy or use for the third dimension, we could well have Class::Klein.
By the way, the limerick has another stanza:
A mathematician called Klein
Thought the möbius band was divine.
He said "If you glue
The edges of two,
You'll get a strange bottle like mine."
--
Oh Lord, wont you burn me a Knoppix CD ?
My friends all rate Windows, I must disagree.
Your powers of persuasion will set them all free,
So oh Lord, wont you burn me a Knoppix CD ?
(Missquoting Janis Joplin)
The idea is worth pursuing. But it's already been done.
I wrote Class::Tie::InsideOut to do just that-- while completely unaware of this thread. (I posted something on London.pm was was sent a link to this.)
It works by using tied hashes to link hash keys to variables in the class namespace, and it enforces encapsulation by only letting methods use keys when there is a variable in the same namespace.