If I may be so bold as to borrow Andy's words out of context from the TT3 discussion list:
"It is a deliberate feature of TT that you can replace a hash with an object and it still works. That's the Uniform Access Principle at work, and I think it's a good one."
What I am suggesting with this patch is that we can give array's the same interchangeability with objects that hashes currently enjoy. I know that it is the most common approach to use hashes as the underlying data type for an object, but it's _not_ the only way. The fact that I'm using a tied array rather than a normal one doesn't really matter.
for those who are curious what in the world i'm doing with my bless( tie( foo ) ) nonsense:
The idea is that the object _is_ the list. By and large I want these objects (and my objects with tied hashes underneath as well) used as simple data types for the majority of their lifespans. But there are things that I need them to be able to do that are outside the scope of what simple data types do. So this rig of object-wrapped-around-tied-datastructure lets me call methods to do those things. It feels very much like virtual methods, except i get to do it in the rest of my code as well, not just in my templates.
The reason I want tied data structures in the first place is that the tie classes implement persistence tied to a SQL database. They populate values from the db and write back any changes without the end-user-coder having to worry about any of it.
Surely i could just do a tied( foo )->method(bar) around one of these rigs whenever i wanted to call on special functionality, but i _want_ the ambiguity between data-type and object. Particularly for my template coders. I don't need to tell them about special conditions surrounding these objects. I just tell them that they're hashes/arrays, but also that they can call some extra virtual methods on them that only work for these particular data structures.
-Stephen
Jeff Anderson wrote:
Sounds neat, but is really buying you anything? I have no idea why you are using a tied array ... i am sure you have a good reason. But without seeing any code or such, i can't help but question why you didn't just have an object that has a method that returns the list you need?
Curious, ;) jeffa
--- Stephen Howard <[EMAIL PROTECTED]> wrote:
I've got an object type that uses a tied arrayhttp://lists.template-toolkit.org/mailman/listinfo/templates
as the underlying data type. For my purposes this lets me use it as
an array for certain behaviors and still call methods on it like an
object. This works great in perl, but Template Toolkit refuses to let me
treat it as an array in my templates. The patch below lets me do that,
though.
Any chances anyone else wants to see this as
well? It seems sensible to me that if the template author hands Stash a
numeric index as an argument, they know they're working with some
form of array. Note to others, you'll have to include an as_list()
subroutine in your class for this little snippet in Template::Iterator to be
happy:
elsif (UNIVERSAL::can($data, 'as_list')) { $data = $data->as_list(); }
here's the patch:
--- Stash.orig.pm Fri Dec 5 17:06:17
2003
+++ Stash.pm Fri Dec 5 16:54:19 2003
@@ -572,7 +572,7 @@
return [EMAIL PROTECTED]@$item}]; ## RETURN
}
}
- elsif ($rootref eq 'ARRAY' ) {
+ elsif ($rootref eq 'ARRAY' || $item =~
/^-?\d+$/ ) {
# if root is an ARRAY then we check for a LIST_OPS pseudo-method # (except for l-values for which it doesn't make any sense)
_______________________________________________ templates mailing list [EMAIL PROTECTED]
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
_______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates
