Re: get_maximized

[Sergei Steshenko <sergstesh yahoo com>]

--- muppet <scott asofyet org> wrote:

> On Sep 6, 2006, at 9:54 AM, Sergei Steshenko wrote:
>
> > --- Emmanuele Bassi <ebassi gmail com> wrote:
> >
> > >       if ($event->changed_mask & [ 'maximized', ]) {
> >
> > Isn't "&" in
> >
> > $event->changed_mask & [ 'maximized', ]
> >
> > bitwise AND ?
>
> In this context, no.  Read about it in the "This is now that" section  
> of the Glib manpage: http://gtk2-perl.sourceforge.net/doc/pod/ 
> Glib.html#This_Is_Now_That
>
> The API was designed this way to allow you to use C-ish syntax if  
> that's what you're used to, or more meaningful syntax if you prefer.   
> The implementations of the operators have the necessary magic to  
> ensure that you get what you mean with various ways to ask for it.
>
> Quoting the manpage:
> > Flags have some additional magic abilities in the form of  
> > overloaded operators:
> >
> >   + or |   union of two flagsets ("add")
> >   -        difference of two flagsets ("sub", "remove")
> >   * or &   intersection of two bitsets ("and")
> >   / or ^   symmetric difference ("xor", you will rarely need this)
> >   >=       contains-operator ("is the left set a superset of the  
> > right set?")
> >   ==       equality
> > In addition, flags in boolean context indicate whether they are  
> > empty or not, which allows you to write common operations naturally:
> >
> >   $widget->set_events ($widget->get_events - "motion_notify_mask");
> >   $widget->set_events ($widget->get_events - ["motion_notify_mask",
> >                                               "button_press_mask"]);
> >
> >   # shift pressed (both work, it's a matter of taste)
> >   if ($event->state >= "shift-mask") { ...
> >   if ($event->state * "shift-mask") { ...
> >
> >   # either shift OR control pressed?
> >   if ($event->state * ["shift-mask", "control-mask"]) { ...
> >
> >   # both shift AND control be pressed?
> >   if ($event->state >= ["shift-mask", "control-mask"]) { ...
>  >
> > In general, + and - work as expected to add or remove flags. To  
> > test whether any bits are set in a mask, you use $mask * ..., and  
> > to test whether all bits are set in a mask, you use $mask >= ....
> >
> > When dereferenced as an array @$flags or $flags->[...], you can  
> > access the flag values directly as strings (but you are not allowed  
> > to modify the array), and when stringified "$flags" a flags value  
> > will output a human-readable version of its contents.
>
>
> --
> Meg: Brian!  Chris picked his nose and keeps trying to touch me with  
> his finger!
> Chris: What good is mining nose gold if I can't share it with the  
> townspeople?
>     -- Family Guy
>
>
> _______________________________________________
> gtk-perl-list mailing list
> gtk-perl-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list

Why was this done in the first place ?

I mean, if one overloads '+'. '-', '*', '/', '|', '&', '^' for,
say, BigInt, this looks intuitive.

But to overload '+'. '-', '*', '/', '|', '&', '^' for strings ?!

Why not to leave it the original "C" way using 'enum' ?

I mean, http://search.cpan.org/~zenin/enum-1.016/enum.pm .

I disagree with the claim that present implemetation leaves
things like they are in gtk+ "C" - I believe it's the opposite.

It would have been the same if masks remained the same
- (unsigned) integer values composed of bits.

--Sergei.


Applications From Scratch: http://appsfromscratch.berlios.de/

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com