[Mason-devel] Defaults in flags()

[David Wheeler]

Fellow Masonites,

Shouldn't the flags() method in Component.pm have a default value set
for the inherit flag?

Index: lib/HTML/Mason/Component.pm
===================================================================
--- lib/HTML/Mason/Component.pm (revision 3767)
+++ lib/HTML/Mason/Component.pm (working copy)
@@ -301,9 +301,9 @@
#
sub flag {
my ($self,$name) = @_;
- my %flag_defaults =
- (
- );
+ my %flag_defaults = (
+ inherit => 1,
+ );
if (exists($self->{flags}->{$name})) {
return $self->{flags}->{$name};
} elsif (exists($flag_defaults{$name})) {

Thanks,

David

[Marius Feraru]

Post by David Wheeler
Shouldn't the flags() method in Component.pm have a default value set
for the inherit flag?

No, because it's automatically set by the "_determine_inheritance"
method (lib/HTML/Mason/Component.pm:109).

Post by David Wheeler
+ my %flag_defaults = (
+ inherit => 1,
+ );

"inherit" should define a component path.

- --
Marius Feraru

[David Wheeler]

Post by Marius Feraru

Post by David Wheeler
Shouldn't the flags() method in Component.pm have a default value set
for the inherit flag?

No, because it's automatically set by the "_determine_inheritance"
method (lib/HTML/Mason/Component.pm:109).

Hrm. But that's a private method, and if it hasn't been called by
Mason before I call flags(), it doesn't work properly.

Post by Marius Feraru
"inherit" should define a component path.

Flags are booleans, I believe. It seems kind of odd that inherit
actually stores something other than a 1 or a 0.

Best,

David

[Hans Dieter Pearcey]

Post by David Wheeler

Post by Marius Feraru
"inherit" should define a component path.

Flags are booleans, I believe. It seems kind of odd that inherit
actually stores something other than a 1 or a 0.

HTML::Mason::Devel says:

the value may be any scalar value, including references

The only flag I know about is 'inherit', so the idea that "flags are
booleans" boggles me. Where did you find it? (non-rhetorical)

hdp.

[Marius Feraru]

Post by David Wheeler

Post by Marius Feraru

Post by David Wheeler
Shouldn't the flags() method in Component.pm have a default value set
for the inherit flag?

No, because it's automatically set by the "_determine_inheritance"
method (lib/HTML/Mason/Component.pm:109).

Hrm. But that's a private method, and if it hasn't been called by
Mason before I call flags(), it doesn't work properly.

Ah (good morning to myself) - now I see your point: there is a _public_
flag() method (and custom flags functionality, OFC).

Post by David Wheeler

Post by Marius Feraru
"inherit" should define a component path.

Flags are booleans, I believe. It seems kind of odd that inherit
actually stores something other than a 1 or a 0.

Agree. But the current functionality of the "inherit" flag in one good
old Mason feature that many of us (me included) would miss if it would
cease to exist. ;-)

Now, what would you prefer flag('inherit') to return?

a) current approach:
exists $self->{flags}{inherit}
? $self->{flags}{inherit}
: undef;

b) boolean:
exists $self->{flags}{inherit} && defined $self->{flags}{inherit}

c) parent component:
$self->parent

d) ? ;-)

cheers
- --
Marius Feraru

[David Wheeler]

Post by Marius Feraru
Ah (good morning to myself) - now I see your point: there is a
_public_
flag() method (and custom flags functionality, OFC).

Exactly. I'm using it in a subclass (essentially) of component, so
I'd rather use the public interface than reach into the flags hash
directly or call a private method.

Post by Marius Feraru
Agree. But the current functionality of the "inherit" flag in one good
old Mason feature that many of us (me included) would miss if it would
cease to exist. ;-)

Yes, Hans explained the issue rather well (and yes, John is right wrt
what I mean about hte use of the term "flags"—especially since there
is a <%flags> block in Mason! But I had forgotten that it didn't
specify only booleans, because Bricolage users actually use it to
turn off inheritance:

<%flags>
$inherit => undef
</%flags>

So I was thinking of it as a boolean.

Post by Marius Feraru
Now, what would you prefer flag('inherit') to return?

I want it to return whatever the inherit flag is set to. In the above
example, it would return undef. If it's not specified in a dhandler,
I assume that it should return the parent.

Uh, but then maybe I could just call parent(), instead? Would it
return undef when I have the inherit flag set to undef in the component?
Best,

David

[David Wheeler]

Post by David Wheeler
Uh, but then maybe I could just call parent(), instead? Would it
return undef when I have the inherit flag set to undef in the
component?

Oh, I see what the problem is. I need to know only when the inherit
flag has been set in a component, and, if it has, what it was set to.
Otherwise I don't worry about it.

So for my method, it would need to be something like this:

my $tmpl_path = '/foo/bar';
my $tmpl_name = 'article.mc';
local *HTML::Mason::Component::inherit_start_path = sub {
my $self = shift;

# Allow template-defined inheritance to work.
return $self->inherit_start_path if exists $self->{flags}
{inherit};

# Use the template path if executing our dhandler.
return $tmpl_path if $self->name =~ m/\Q$tmpl_name\E$/;

# Otherwise, just fall back on Mason's default.
return $self->inherit_start_path;
};

So I guess that I'm only interested in the existence of a flag.

Best,

David

[John Williams]

Post by Hans Dieter Pearcey

Post by David Wheeler

Post by Marius Feraru
"inherit" should define a component path.

Flags are booleans, I believe. It seems kind of odd that inherit
actually stores something other than a 1 or a 0.

the value may be any scalar value, including references
The only flag I know about is 'inherit', so the idea that "flags are
booleans" boggles me. Where did you find it? (non-rhetorical)

I think he is referring the dictionary definition of flag, as used in
computer programming.

http://www.worldwideschool.org/library/books/tech/computers/TheHackersDictionaryofComputerJargon/chap25.html

In mason, the flags section is for non-inherited, private attributes.
So he is right. We are misusing the term a bit.

~ John Williams