[wxperl-users] your wxPerl wishlist?

Hi all,

I'm working on a few ideas for better expressing wx child widgets and 
layouts in Perl and I'm curious what you think is most needed.

First, let me say a big thank you to Mattia.  I've been using wxPerl for 
a while now and am fairly familiar with the code and what a monumental 
effort this was and is.  Mattia, you deserve many more thank-you's and 
likely don't hear them often enough.  What I'm working on is something 
like an "ideal syntax", not any sort of flaw in the bindings.

Next, I've heard "I want a good, free GUI rad tool" before, and to be 
honest, I have no interest in that sort of thing or that line of 
discussion and thus no intention to do anything about it.  Sorry, wrong 
thread.  If someone has an adequately smalltalkish inspiration for 
wedding the tool to the code, it might be applicable.  Otherwise, no.

And, we all know about the lack-of-perl-specific-documentation issue, so 
let's take that one as read.

So, now that we're talking about code rather than tools...  What are 
your nits and peeves about creating, using, and configuring widgets?

Mine are roughly as follows.  Aside:  As trivial as some may seem, the 
sum of trivialities is non-trivial, and I think part of what makes Perl 
special is that speed-bumps and trivial nits were eliminated early in 
the design.  (If you haven't studied a little python, ruby, C++, or 
other languages, you might not yet appreciate Perl's amazing lack of 
hindrances (and then look at perl6!))  Also, a cursory glance at Jifty 
and Moose might help to shed some light on how I'm thinking and what is 
possible.

Many of my issues could probably be summarized as "Perl ain't C++".

A.  Too many constants and imports.
For better or worse, perl5 subroutines are methods.  Having all of these 
constants in my namespace bothers me greatly.  Wx::wxDefaultPosition()  
isn't any fun to type either.  EVT_foobarbazbork() also seems rather 
wrong in some way.

B.  Long method calls and positional parameters.
I don't want lines longer than 72 characters in my code, but even when 
indenting only 2 spaces, it is almost impossible to construct and style 
a TextCtrl in 1-2 lines.  Further, distending a call with positional 
parameters gets clunky very quickly.  Now, assign the resultant object 
to $self->{that_thingy} and you have to get out your spectacles to 
figure out what's happening.  Alternatively, spend 20 lines per 
sub-widget (which is just too much code to read.)

C.  Flags
e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a mouthful, 
and I typically have to look in the documentation anyway.  With so many 
options, the business of constructing flags via or'd constants gets 
noisy rather quickly.

D.  XRC (sort of)
I've done some XRC research and preliminary experiments, but don't see 
it being a solution because (1) it is slow (startup time on a very 
simple frame layout is longer than the whole of dotReader load-time) 
and (2) it seems to rather limit control despite the verbosity penalty 
of XML, plus the "load, then get" usage (aka "why isn't the dom my 
object?".)  I say "sort of" here because it can't really be much of a 
pain-point if it's not actually viable.  But, I bring it up because 
maybe I'm totally wrong and somebody will clue-stick me.

So, that's the executive summary of my wishlist.  It basically comes 
down to very distinct differences (visually and architecturally) 
between "Perl code" and "Wx code".

Please append, confirm, or dispute according to your experiences.



The rest of this message is an alpha-release brain-dump of my current 
line-of-thought...  If you're interested in helping me hammer on the 
specifics of this idea, please change the subject line.  I'm only 
including this as background on the above line of inquiry.

I'm working on an idea to create a set of classes with a mixture of 
named and positional parameters (e.g. the positional ones being the 
ones that don't come with 'foo = somedefault' in the C++ headers.)  
This would be a sort of "normal form" for all of the Wx::Foo->new() 
constructors.

Building on top of that, a declarative syntax which would build and 
install methods to create, configure, and layout your widgets as well 
as making accessors for the resultant objects.  A *very* preliminary 
snapshot of what this looks like is:

  use WxPerl::Declare;
  bitmaps sub {shift->choose_bitmap(@_)},
  children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),
    code { # setup special thingy...
      my $self = shift;
      warn "this runs on $self here";
    },
    ctrl dismiss_button => -Button => '&Close',
    ctrl details_button => -Button => '&Details',
  );
  layout(
    h_split qw(right_window bv_manager note_viewer),
    v_split qw(window_1 sidebar right_window 195),
    # still working on how this comes together
    box->vertical->items(qw(...)), # ?
    -BoxSizer => [
      vertical => {'sizer options here?' => 'foo'},
      object_identifier => [@sizer_Add_opts],
    ],
  );
  no  WxPerl::Declare;

  ...

  # in new() or init()
  $self->__create_children;
  $self->__do_layout;

Where [custom_bit, text_ctrl, dissmiss_button, details_button, 
right_window, bv_manager, note_viewer, window_1, sidebar, and 
right_window] are all names for the accessors of the subwidgets.  The 
'ctrl', and 'code' keywords are directives (think of them as road-signs 
in the argument list.)  The sizer stuff still needs some thought, so 
ignore the internals of layout().  The main point is that children() 
and layout() create the methods __create_children() and __do_layout(), 
which you then call later (once you have a $self.)  By moving all of 
the create, configure, and layout into a declarative "header" on your 
class, you don't have to write the longhand code for widget creation 
and layout.  It definitely compacts the declaration.  I'm hoping it 
will also make it more readable (and maybe more importantly: 
skimmable.)  Note that $self is implied just about everywhere.  I'm 
also throwing numeric id's out the window (as far as the interface is 
concerned) under the assumption that providing named accessors for the 
objects is way better.

Aside:  If you don't believe that is Perl (with no source filters), just 
take my word for it, or read up on Moose and Jifty.  Hey, I haven't 
even gotten as far as abusing indirect object syntax!

Again, this is *preliminary* thinking.  You can assist by adding entropy 
and/or information.

Thanks,
Eric
-- 
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/17/2007 10:17:08 AM
perl.wxperl.users 3070 articles. 0 followers. Follow

22 Replies
615 Views

Similar Articles

[PageSpeed] 2

Eric Wilhelm <scratchcomputing@gmail.com> writes:

> Mattia, you deserve many more thank-you's and likely don't hear them
> often enough.

I second this!

> Next, I've heard "I want a good, free GUI rad tool" before, and to
> be honest, I have no interest in that sort of thing or that line of
> discussion and thus no intention to do anything about it.

I think this is an very unfortunate attitude.

As many people here know, I'm a fan of wxGlade. wxGlade provides a
great help in setting up user interfaces and generates good Perl code.
Many of the things that bother you when using wxPerl do not bother me,
since they're part of automatically generated code that I don't have
to maintain. I even don't care to look at this code except for
educational purposes.

> A.  Too many constants and imports.
> [...] Having all of these constants in my namespace bothers me
> greatly.

This has never bothered me.

> B.  Long method calls and positional parameters.
> [...] it is almost impossible to construct and style a TextCtrl in
> 1-2 lines.

Take your time, take your space. I don't see any problems with:

  $self->{tx_log} = Wx::TextCtrl->new
  ($self, -1, "",
   wxDefaultPosition, wxDefaultSize,
   wxTE_MULTILINE|wxTE_READONLY|wxHSCROLL);

I try to avoid long lines as well, but I don't mind a complex
statement to take several lines.

> C.  Flags
> e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a
> mouthful, and I typically have to look in the documentation anyway.
> With so many options, the business of constructing flags via or'd
> constants gets noisy rather quickly.

This is one of the areas where wxGlade does a fine job in taking your
troubles away.

>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",

I find it hard to see where the ctrl custom_bit arguments end, and the
new ctrl starts. Reading the above line I'd expect "ctrl text_ctrl" to
be an argument of "ctrl custom_bit".

>          style(te => 'MULTILINE|READONLY|DONTWRAP'),

This is only marginally better than
wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP.

>     ctrl dismiss_button => -Button => '&Close',
>     ctrl details_button => -Button => '&Details',

You're taking away the possibility to use stock buttons. It would be
better to use something like:

    ctrl dismiss_button => -Button => CLOSE,
    ctrl details_button => -Button => DETAILS,

and leave the rest (standard Ids, labels) to Wx.

>   layout(
>     h_split qw(right_window bv_manager note_viewer),
>     v_split qw(window_1 sidebar right_window 195),
>     # still working on how this comes together
>     box->vertical->items(qw(...)), # ?
>     -BoxSizer => [
>       vertical => {'sizer options here?' => 'foo'},
>       object_identifier => [@sizer_Add_opts],
>     ],
>   );

I'm afraid you either have to leave out many features that probable
need to be added in due time anyway, or make it as complex as it
currently is when using wxPerl directly.

Then again, many, if not all, these worries are taken awy by using
wxGlade or similar tools.

>   # in new() or init()
>   $self->__create_children;
>   $self->__do_layout;

Why the double underscore? Obfuscation?

> Again, this is *preliminary* thinking. You can assist by adding
> entropy and/or information.

As usual, I appreciate your thinking and braindumps very much. In this
particular case I'm afraid you're trying to reinvent a wheel that's
already comfortably running for many other wxPerl users.

Having said that, there are lots of things that can be improved on
wxGlade.

-- Johan

0
jvromans
3/17/2007 11:59:26 AM
Hi Eric and All,

This counts as entropy, I think.

I have been working on something that scratches similar itches, but in
slightly different ways. Some of my main 'itches' were the same as
yours, I think:

or'd flags - I always have to visit the manual

EVT_MACRO syntax - always have to look this up even though its very
simple - as you say, it seems wrong.

object constructors - always have to visit the manual.

Using (rather cheekily) the namespace VP, I was drawn towards creating a
series of classes for the GUI components.

So, if you inherit from VP::Frame you get an additional constructor:

my $frame = MyFrame->VPNew();

VPNew accepts optional hash parameters:

my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );

Internally it applies defaults to any missing params before calling its
own 'new'. Its own 'new' does the $class->SUPER::new(@) before calling

$self->__after_new()
$self->__create_controls()
$self->__create_events()
$self->__layout()

which in turn call

$self->VPOnNew()
$self->VPOnCreateControls()
$self->VPOnCreateEvents()
$self->VPOnLayout()

which can be overridden in the derived class. I had four simply because
it adds a helpful structure when you come to write documentation. There
are two procs for each 'section' because down the line I have an itch
which you don't share which is a bit of a dialog designer - but that's a
separate thread.

There is also $self->VPOnClose() which does the sensible thing for most
situations.

For sizers, I looked at the possibility of subclassing and decided no.
I stuck some methods in a common class inherited by my toplevel windows
and containers like
$self->CreateBoxSizer() which take perl hash arguments or return
sensible default sizers.

Underlying it all, I wanted to make this provide an easier interface to
starting with Wx. I've long since abandon thoughts of perlifying the
wxWidgets manual, so, assuming I document the VP__ methods, folks have
to be able to figure everything else out from the wxWidgets manual.
Which brings me to EVT_MACRO syntax.

I think all that may be needed here is prominent documentation of the
$evthandler->Connect($evtsource, $evtidstart, $evtidend, $functionref);
syntax with a pointer to the alternative event macro style.

Add a couple of documented VP methods to make it even easier:
$evthandler->VPConnectEvent($evtsource, $evttype, $functionref);
$evthandler->VPConnectEventRange($evtsource, $startid, $endid,
$functionref);

I think I would personally have found this easier to use, but the
EVT_MACRO syntax is a very clever way of making the wxWidgets docs
easier to follow. I'd still have to visit the docs to look up the event
types, of course.

On XRC, I've never seen the point of this in Perl, an interpreted
language - I have no desire to share templates across different
languages. There are better perl specific ways to do this.

Your WxPerl::Declare stuff looks very interesting.
My own stuff keeps collections of named child objects allowing
$frame->VPGet('childname') syntax or
$frame->VPGet('childname1','childname2','childname3');
for children of child containers.

$frame->childname1->childname2->childname3();
looks much more attractive.

I'm not sure that the syntax that gets you there fulfills my own goal of
allowing easier entry to Wx usage. I'd have to play for a while.

Hmmm. Same itches but differing solutions.

Regards

Mark



Eric Wilhelm wrote:
> Hi all,
> 
> I'm working on a few ideas for better expressing wx child widgets and 
> layouts in Perl and I'm curious what you think is most needed.
> 
> First, let me say a big thank you to Mattia.  I've been using wxPerl for 
> a while now and am fairly familiar with the code and what a monumental 
> effort this was and is.  Mattia, you deserve many more thank-you's and 
> likely don't hear them often enough.  What I'm working on is something 
> like an "ideal syntax", not any sort of flaw in the bindings.
> 
> Next, I've heard "I want a good, free GUI rad tool" before, and to be 
> honest, I have no interest in that sort of thing or that line of 
> discussion and thus no intention to do anything about it.  Sorry, wrong 
> thread.  If someone has an adequately smalltalkish inspiration for 
> wedding the tool to the code, it might be applicable.  Otherwise, no.
> 
> And, we all know about the lack-of-perl-specific-documentation issue, so 
> let's take that one as read.
> 
> So, now that we're talking about code rather than tools...  What are 
> your nits and peeves about creating, using, and configuring widgets?
> 
> Mine are roughly as follows.  Aside:  As trivial as some may seem, the 
> sum of trivialities is non-trivial, and I think part of what makes Perl 
> special is that speed-bumps and trivial nits were eliminated early in 
> the design.  (If you haven't studied a little python, ruby, C++, or 
> other languages, you might not yet appreciate Perl's amazing lack of 
> hindrances (and then look at perl6!))  Also, a cursory glance at Jifty 
> and Moose might help to shed some light on how I'm thinking and what is 
> possible.
> 
> Many of my issues could probably be summarized as "Perl ain't C++".
> 
> A.  Too many constants and imports.
> For better or worse, perl5 subroutines are methods.  Having all of these 
> constants in my namespace bothers me greatly.  Wx::wxDefaultPosition()  
> isn't any fun to type either.  EVT_foobarbazbork() also seems rather 
> wrong in some way.
> 
> B.  Long method calls and positional parameters.
> I don't want lines longer than 72 characters in my code, but even when 
> indenting only 2 spaces, it is almost impossible to construct and style 
> a TextCtrl in 1-2 lines.  Further, distending a call with positional 
> parameters gets clunky very quickly.  Now, assign the resultant object 
> to $self->{that_thingy} and you have to get out your spectacles to 
> figure out what's happening.  Alternatively, spend 20 lines per 
> sub-widget (which is just too much code to read.)
> 
> C.  Flags
> e.g. "wxTE_MULTILINE|wxTE_READONLY|wxTE_DONTWRAP" -- It's a mouthful, 
> and I typically have to look in the documentation anyway.  With so many 
> options, the business of constructing flags via or'd constants gets 
> noisy rather quickly.
> 
> D.  XRC (sort of)
> I've done some XRC research and preliminary experiments, but don't see 
> it being a solution because (1) it is slow (startup time on a very 
> simple frame layout is longer than the whole of dotReader load-time) 
> and (2) it seems to rather limit control despite the verbosity penalty 
> of XML, plus the "load, then get" usage (aka "why isn't the dom my 
> object?".)  I say "sort of" here because it can't really be much of a 
> pain-point if it's not actually viable.  But, I bring it up because 
> maybe I'm totally wrong and somebody will clue-stick me.
> 
> So, that's the executive summary of my wishlist.  It basically comes 
> down to very distinct differences (visually and architecturally) 
> between "Perl code" and "Wx code".
> 
> Please append, confirm, or dispute according to your experiences.
> 
> 
> 
> The rest of this message is an alpha-release brain-dump of my current 
> line-of-thought...  If you're interested in helping me hammer on the 
> specifics of this idea, please change the subject line.  I'm only 
> including this as background on the above line of inquiry.
> 
> I'm working on an idea to create a set of classes with a mixture of 
> named and positional parameters (e.g. the positional ones being the 
> ones that don't come with 'foo = somedefault' in the C++ headers.)  
> This would be a sort of "normal form" for all of the Wx::Foo->new() 
> constructors.
> 
> Building on top of that, a declarative syntax which would build and 
> install methods to create, configure, and layout your widgets as well 
> as making accessors for the resultant objects.  A *very* preliminary 
> snapshot of what this looks like is:
> 
>   use WxPerl::Declare;
>   bitmaps sub {shift->choose_bitmap(@_)},
>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",
>          style(te => 'MULTILINE|READONLY|DONTWRAP'),
>     code { # setup special thingy...
>       my $self = shift;
>       warn "this runs on $self here";
>     },
>     ctrl dismiss_button => -Button => '&Close',
>     ctrl details_button => -Button => '&Details',
>   );
>   layout(
>     h_split qw(right_window bv_manager note_viewer),
>     v_split qw(window_1 sidebar right_window 195),
>     # still working on how this comes together
>     box->vertical->items(qw(...)), # ?
>     -BoxSizer => [
>       vertical => {'sizer options here?' => 'foo'},
>       object_identifier => [@sizer_Add_opts],
>     ],
>   );
>   no  WxPerl::Declare;
> 
>   ...
> 
>   # in new() or init()
>   $self->__create_children;
>   $self->__do_layout;
> 
> Where [custom_bit, text_ctrl, dissmiss_button, details_button, 
> right_window, bv_manager, note_viewer, window_1, sidebar, and 
> right_window] are all names for the accessors of the subwidgets.  The 
> 'ctrl', and 'code' keywords are directives (think of them as road-signs 
> in the argument list.)  The sizer stuff still needs some thought, so 
> ignore the internals of layout().  The main point is that children() 
> and layout() create the methods __create_children() and __do_layout(), 
> which you then call later (once you have a $self.)  By moving all of 
> the create, configure, and layout into a declarative "header" on your 
> class, you don't have to write the longhand code for widget creation 
> and layout.  It definitely compacts the declaration.  I'm hoping it 
> will also make it more readable (and maybe more importantly: 
> skimmable.)  Note that $self is implied just about everywhere.  I'm 
> also throwing numeric id's out the window (as far as the interface is 
> concerned) under the assumption that providing named accessors for the 
> objects is way better.
> 
> Aside:  If you don't believe that is Perl (with no source filters), just 
> take my word for it, or read up on Moose and Jifty.  Hey, I haven't 
> even gotten as far as abusing indirect object syntax!
> 
> Again, this is *preliminary* thinking.  You can assist by adding entropy 
> and/or information.
> 
> Thanks,
> Eric



0
mark
3/17/2007 12:18:16 PM
Re prior post:

Just in case anyone is looking at the example

my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );

and wondering what on earth 'bordertop' is, it is a duff example.

It has always seemed more natural to me to define control layout in
terms of the controls themselves so a 'proper' example would be

my $txtctrl = MyInheritsVPText->VPNew( bordertop => 0 );
VP->AddToSizer( $mysizer, $txtctrl );

So the AddToSizer function grabs the Add params from $txtctrl which
itself provides sensible defaults.


Mark



0
mark
3/17/2007 12:37:42 PM
Hello

I just came across Wx::WidgetMaker

http://search.cpan.org/~slanning/Wx-WidgetMaker-0.11/lib/Wx/WidgetMaker.pm

Which is an attempt to ease the creation of wx based applications.

I havent tested that though but I'm interested to see what you think 
about this.

Eriam


Mark Dootson a �crit :
> Re prior post:
>
> Just in case anyone is looking at the example
>
> my $frame = MyInherits->VPNew( title => 'My Window', bordertop => 0 );
>
> and wondering what on earth 'bordertop' is, it is a duff example.
>
> It has always seemed more natural to me to define control layout in
> terms of the controls themselves so a 'proper' example would be
>
> my $txtctrl = MyInheritsVPText->VPNew( bordertop => 0 );
> VP->AddToSizer( $mysizer, $txtctrl );
>
> So the AddToSizer function grabs the Add params from $txtctrl which
> itself provides sensible defaults.
>
>   


0
eriam
3/17/2007 2:00:17 PM
Eriam Schaffter wrote:

Hello,

Wx::WidgetMaker is interesting because it does some of the things
suggested previously. I must admit, I'd never read past the word 'CGI'
before. For me, 'CGI.pm like' would be the wrong starting point.

As the author of the module says, its 'a CGI.pm-like library for wxPerl'.

For me, I feel that starting out to emulate CGI.pm would be a very
limiting approach that might not lend itself well to as rich an
environment as wxPerl. But that's really really not a criticism of
Wx::WidgetMaker which does exactly what it says on the tin.

Perhaps I have a minority viewpoint on this. I came to Perl first via
data munging and DBI. If my entry point had been CGI then perhaps my
view would be different.

Regards

Mark



> Hello
> 
> I just came across Wx::WidgetMaker
> 
> http://search.cpan.org/~slanning/Wx-WidgetMaker-0.11/lib/Wx/WidgetMaker.pm
> 
> Which is an attempt to ease the creation of wx based applications.
> 
> I havent tested that though but I'm interested to see what you think
> about this.
> 
> Eriam


0
mark
3/17/2007 2:40:00 PM
# from Johan Vromans
# on Saturday 17 March 2007 04:59 am:

>> Next, I've heard "I want a good, free GUI rad tool" before, and to
>> be honest, I have no interest in that sort of thing or that line of
>> discussion and thus no intention to do anything about it.
>
>I think this is an very unfortunate attitude.

What!?  I'm trying to be pragmatic here.  Code generation doesn't work, 
so I don't think it is worth discussing.

I only intended that to set the topic as "not wxglade."  If you want to 
use it, fine.  I prefer to write clean, concise code rather than wade 
through piles of generated muck.

>As many people here know, I'm a fan of wxGlade. wxGlade provides a
>great help in setting up user interfaces and generates good Perl code.
>Many of the things that bother you when using wxPerl do not bother me,
>since they're part of automatically generated code that I don't have
>to maintain. I even don't care to look at this code except for
>educational purposes.

Thanks.  Now to untrim the important bit of that paragraph:

>>Sorry, wrong thread.  If someone has an adequately smalltalkish
>>inspiration for wedding the tool to the code, it might be applicable.
>>Otherwise, no. 

I'm not saying "it can't be done" or "I won't allow it."  Rather, THIS 
IS NOT SMALLTALK!  No matter what wxglade or other tool does, it still 
has to generate a text file, which is an all-or-nothing operation.  
Even with the "start" and "end" markers, you're left with a blob of 
code that can't be changed in your editor.  It's a one-way street, 
which means the workflow is perverted into something like "make, then 
edit."  Until a gui tool can deal with *incoming* changes to the code, 
we're not even close to solving this.  Now, make the tool and the 
editor communicate via a mechanism that doesn't involve conflicting 
overwrites on one file.  Ok?  See why we're in the wrong environment to 
enable this sort of thing?  You might be fine with the way it works, 
but it is so far from optimal that I see it as having started from a 
*completely* wrong set of assumptions.

It doesn't count as wheel-reinvention if the current wheel won't roll.

--Eric
-- 
Those who cannot remember the past are condemned to repeat it.
--George Santayana
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/17/2007 6:04:29 PM
Eric Wilhelm wrote:
> IS NOT SMALLTALK!  No matter what wxglade or other tool does, it still 
> has to generate a text file, which is an all-or-nothing operation.  
> Even with the "start" and "end" markers, you're left with a blob of 
> code that can't be changed in your editor.  It's a one-way street, 
> which means the workflow is perverted into something like "make, then 
> edit."  Until a gui tool can deal with *incoming* changes to the code, 
> we're not even close to solving this. 

Nah.

Have the GUI tool generate a separate template class from which you
inherit. Never edit the template class 'cause it just has your window
construction stuff in it.
Edit your derived class in whatever you like.

So that's it solved.

Mark



0
mark
3/17/2007 6:22:24 PM
# from Mark Dootson
# on Saturday 17 March 2007 11:22 am:

>Eric Wilhelm wrote:
>> IS NOT SMALLTALK!  No matter what wxglade or other tool does, it
>> still has to generate a text file, which is an all-or-nothing
>> operation. Even with the "start" and "end" markers, you're left with
>> a blob of code that can't be changed in your editor.  It's a one-way
>> street, which means the workflow is perverted into something like
>> "make, then edit."  Until a gui tool can deal with *incoming*
>> changes to the code, we're not even close to solving this.
>
>Nah.
>
>Have the GUI tool generate a separate template class from which you
>inherit. Never edit the template class 'cause it just has your window
>construction stuff in it.
>Edit your derived class in whatever you like.
>
>So that's it solved.

Right, and that's what I was doing until I ran into problems.  It's not 
solved because it's still a one-way street, wxglade still generates 
code that doesn't do what I want in some cases, drops menu-items on the 
floor (requiring me to maintain a mirror of numeric ID's), etc.  If it 
were solved, I would be a happy clam, but I'm not.

--Eric
-- 
Those who cannot remember the past are condemned to repeat it.
--George Santayana
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/17/2007 8:16:32 PM
Eric Wilhelm wrote:

> Right, and that's what I was doing until I ran into problems.  It's not 
> solved because it's still a one-way street, wxglade still generates 
> code that doesn't do what I want in some cases, drops menu-items on the 
> floor (requiring me to maintain a mirror of numeric ID's), etc.  If it 
> were solved, I would be a happy clam, but I'm not.
> 

So ... (and sorry for getting all gui designer specific) what's needed
is a dialog designer written in perl that gets 80% of things right so
you can fix the other 20% to meet your own needs. The thing is, once one
has attained the level of basic competence that allows one to make a
reasonable job of writing such a thing - one has probably lost a lot of
the incentive to do so. I'm just going to attempt to get the ball
rolling by shoving something out that does stuff the way I want it to.

With regard to your WxPerl::Declares section, the main attraction to me
 is getting named accessors for your child controls /menus /toolbars
etc. I think I'd consider something a touch more verbose involving
Class::Accessor::Fast. As it stands, the syntax does look very inaccessible.

Good luck with it.

Mark







0
mark
3/17/2007 9:13:30 PM
# from Mark Dootson
# on Saturday 17 March 2007 02:13 pm:

>the main attraction to me is getting named accessors for your child
>controls /menus /toolbars etc.

Yes, I think that's fairly key to cleaning up the syntax.  Assignment 
statements which could be taken as implied should be.  The same goes 
for $self (though this is understandably where some people get scared 
and say "whoa, not so fast.")

>I think I'd consider something a touch more verbose

Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
good about verbose?  XML?

>involving Class::Accessor::Fast.

I've run into problems with the typical 'use base qw(Class::Accessor)' 
approach and multiple inheritance.  Maybe I want a new() method from a 
package in which I want to override a foo() method with a generated 
accessor, but the Class::Accessor scheme says "too bad, you get my 
new()."  The solution that I came up with involves letting the accessor 
generator have it's way with a "secret" base class.  While I was at it, 
I realized we can get rid of the whole __PACKAGE__->mk_foo() stuff too.

  http://search.cpan.org/search?module=Class%3A%3AAccessor%3A%3AClassy

>With regard to your WxPerl::Declares section...
>As it stands, the syntax does look very inaccessible.

What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
understand the aversion to magic, but once you know the trick, it's not 
magic anymore.

Do you have a suggestion (even if you don't think it would compile, I 
would like to see it.)

There are a lot of component parts that I'm trying to put together, and 
I'm trying to leave out any syntax that isn't needed.

Thus, the arguments to children() are a flat list, where the keyword 
'ctrl' (this is actually a subroutine "sub ctrl ($) {$ctrl_token, @_}") 
marks the start of a new control declaration.

  children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),
    ...

You could probably sprinkle some parenthesis in there without breaking 
anything, but that might mean you needed to quote more.  I'm also 
considering having ctrl() be a completely different beast, but I 
haven't come up with a way to manage that without package variables or 
something which otherwise assumes a state.  The benefit of using 
$ctrl_token is that everything is a list of inputs to children() rather 
than individual statements.  This allows children() to handle lots of 
implied stuff such as $self, and I think makes it easier to build the 
single subref which gets installed as the __create_children() method 
(double-underscores are for wxglade replacement compatibility.)

--Eric
-- 
Turns out the optimal technique is to put it in reverse and gun it.
--Steven Squyres (on challenges in interplanetary robot navigation)
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/17/2007 9:57:13 PM
--- Eric Wilhelm <scratchcomputing@gmail.com> wrote:

> # from Mark Dootson
> # on Saturday 17 March 2007 02:13 pm:
> 
> >the main attraction to me is getting named accessors for your child
> >controls /menus /toolbars etc.
> 
> Yes, I think that's fairly key to cleaning up the syntax.  Assignment 
> statements which could be taken as implied should be.  The same goes 
> for $self (though this is understandably where some people get scared 
> and say "whoa, not so fast.")
> 
> >I think I'd consider something a touch more verbose
> 
> Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
> good about verbose?  XML?
> 
> >involving Class::Accessor::Fast.
> 
> I've run into problems with the typical 'use base qw(Class::Accessor)' 
> approach and multiple inheritance.  Maybe I want a new() method from a 
> package in which I want to override a foo() method with a generated 
> accessor, but the Class::Accessor scheme says "too bad, you get my 
> new()."  The solution that I came up with involves letting the accessor 
> generator have it's way with a "secret" base class.  While I was at it, 
> I realized we can get rid of the whole __PACKAGE__->mk_foo() stuff too.
> 
>   http://search.cpan.org/search?module=Class%3A%3AAccessor%3A%3AClassy
> 
> >With regard to your WxPerl::Declares section...
> >As it stands, the syntax does look very inaccessible.
> 
> What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
> understand the aversion to magic, but once you know the trick, it's not 
> magic anymore.
> 
> Do you have a suggestion (even if you don't think it would compile, I 
> would like to see it.)
> 
> There are a lot of component parts that I'm trying to put together, and 
> I'm trying to leave out any syntax that isn't needed.
> 
> Thus, the arguments to children() are a flat list, where the keyword 
> 'ctrl' (this is actually a subroutine "sub ctrl ($) {$ctrl_token, @_}") 
> marks the start of a new control declaration.
> 
>   children(
>     ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
>     ctrl text_ctrl  => -TextCtrl => "",
>          style(te => 'MULTILINE|READONLY|DONTWRAP'),
>     ...
> 
> You could probably sprinkle some parenthesis in there without breaking 
> anything, but that might mean you needed to quote more.  I'm also 
> considering having ctrl() be a completely different beast, but I 
> haven't come up with a way to manage that without package variables or 
> something which otherwise assumes a state.  The benefit of using 
> $ctrl_token is that everything is a list of inputs to children() rather 
> than individual statements.  This allows children() to handle lots of 
> implied stuff such as $self, and I think makes it easier to build the 
> single subref which gets installed as the __create_children() method 
> (double-underscores are for wxglade replacement compatibility.)
> 
> --Eric
> -- 
> Turns out the optimal technique is to put it in reverse and gun it.
> --Steven Squyres (on challenges in interplanetary robot navigation)
> ---------------------------------------------------
>     http://scratchcomputing.com
> ---------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxperl-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
> 

I am not sure I clearly understand what it's about, but why new syntax/language
to describe hierarchical relationship if Perl already supports hierarchical data
structures ?

Something like that:

my $children_array_ref = # or should it be hash ref ?
  [
    { # first child
    custom_bit =>
      {
      type => 'ctrl',
      class => 'Thing::Control',
      args =>
        {
        arg1 => value1,
        ...
        argN => valueN
        }
      }, # custom_bit

    text_ctrl =>
      {
      type => 'ctrl',
      label => "", # I'm not sure about this
      style =>
        {
        te => MULTILINE|READONLY|DONTWRAP # these are meant to be bitwise OR'ed constants
        }
      }
    },

    { # second child
    ...
    }
  ];


Whenever I see another language inside Perl, I'm getting really nervous
- another (possibly incomplete) definition, another (possibly buggy) parser ...

....

Well, the original example is likely still Perl, but why a subroutine where
plain hierarchical data structure should suffice ?


Regards,
  Sergei.

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


 
____________________________________________________________________________________
8:00? 8:25? 8:40? Find a flick in no time 
with the Yahoo! Search movie showtime shortcut.
http://tools.search.yahoo.com/shortcuts/#news

0
sergstesh
3/18/2007 2:16:02 AM
Eric Wilhelm wrote:

> Hmm...  I'm trying to make it *less* verbose and more concise.  What's 
> good about verbose?  XML?

We're in different camps here. I view it as a Coke vs Pepsi thing. A
matter of personal taste. And XML is a very good thing when used in an
appropriate context. (Which, I'll admit, is quite infrequently.)
I think parenthesis and more quoting is good and I also, as a general
rule, think 'implicit' anything should only be allowed in an argument
list. But there is no right or wrong here. Just different viewpoints.

> What specifically makes it inaccessible?  Or, is it just unfamiliar?  I 
> understand the aversion to magic, but once you know the trick, it's not 
> magic anymore.

Well, unfamiliar = inaccessible surely? Coke vs Pepsi again, I think.

> Do you have a suggestion (even if you don't think it would compile, I 
> would like to see it.)

I have no code. As noted in a prior mail, I'm presently stuck with

->MyGetControlMethod('controlname');
->MyGetMenuMethod('menuname');

which, of course, works and is I think at least better than
$self->{controlname} or $self->{menuitemisaved}.

I'm undecided on the named accessor thing. On the one hand I think that
any accessors in your classes should behave in a standard way vs
inheritance whether hard coded or added at runtime and if you can't
achieve that you should leave it alone. On the other hand, accessors for
controls would be sooooo nice and you could always take the view that in
practical terms, approach X does the job so lets go for it. Then again,
would it be wise to implement your own scheme rather than the commonly
used Class::Accessor with its known limitations / workarounds? I'm
firmly on the fence today.

I've spent some time staring at

children(
    ctrl custom_bit => 'Thing::Control' => 'argument', 'argument',
    ctrl text_ctrl  => -TextCtrl => "",
         style(te => 'MULTILINE|READONLY|DONTWRAP'),

and I can't learn to love it. Perhaps I could learn to love what it does.

Anyhow, if no-one comes up with what you consider a better accessor
scheme it would be great if you actually implemented it. Its the
accessor creation scheme that really matters and how it sits with
use base qw( one two three four );
If I want a more verbose 'children()' that bit alone would be simple.

I'm going to crack on with my pseudo designer template thing. After
spending so much verbage talking about it, it would be shameful if I
didn't produce at least something!
If I stick with MyGetControlMethod('controlname') for now, I can defer
deciding about named accessors until I fall off the fence one way or the
other.

Regards

Mark









0
mark
3/18/2007 4:03:14 AM
# from Mark Dootson
# on Saturday 17 March 2007 07:40 am:

>For me, I feel that starting out to emulate CGI.pm would be a very
>limiting approach that might not lend itself well to as rich an
>environment as wxPerl. But that's really really not a criticism of
>Wx::WidgetMaker which does exactly what it says on the tin.

It would be rather limiting, but no is html.  It would be interesting to 
see it in use as a way to modularize the code off of your web-app and 
turn it into a standalone (or thick-client) app via polymorphism.

--Eric
-- 
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/18/2007 9:41:42 AM
# from Sergei Steshenko
# on Saturday 17 March 2007 07:16 pm:

>I am not sure I clearly understand what it's about, but why new
> syntax/language to describe hierarchical relationship if Perl already
> supports hierarchical data structures ?

One word:  concisification

>my $children_array_ref =3D # or should it be hash ref ?

No, order matters.

>=A0 [
>=A0 =A0 { # first child

oops, we lost the order now

>=A0 =A0 custom_bit =3D>
>=A0 =A0 =A0 {
=2E..
>=A0 =A0 text_ctrl =3D>
>=A0 =A0 =A0 {
>=A0 =A0 =A0 type =3D> 'ctrl',
>=A0 =A0 =A0 label =3D> "", # I'm not sure about this
>=A0 =A0 =A0 style =3D>
>=A0 =A0 =A0 =A0 {
>=A0 =A0 =A0 =A0 te =3D> MULTILINE|READONLY|DONTWRAP=20
>=A0 =A0 =A0 =A0 # these are meant to be bitwise OR'ed constants=20
>    =A0 =A0 }=20

Yeah, but the te =3D> 'string|string|string' means the style() function=20
can append wxTE_ to the front, so-as to Wx->"wxTE_$thing" it.

>=A0 =A0 =A0 }
>=A0 =A0 },
>
>=A0 =A0 { # second child
>=A0 =A0 ...
>=A0 =A0 }
>=A0 ];

>Whenever I see another language inside Perl, I'm getting really
> nervous - another (possibly incomplete) definition, another (possibly
> buggy) parser ...

Nope, no parser.

>Well, the original example is likely still Perl, but why a subroutine
> where plain hierarchical data structure should suffice ?

The data structure would basically have to be array refs all the way=20
down.  Also, the style() function does some mapping.  The idea was=20
basically to make a mini-language that would add some unverbosity and=20
other conveniencification.

(The Bushism-ated words are jokes.  You should laugh now.  I'm not=20
really going to extendify the language like that.)

A sufficiently expressive data-structure would be good, but it wouldn't=20
be declarative.  The benefit of the declarative bits of code is that=20
their procedural guts can remove the need for ']]]]]]]]]]'(did I get=20
enough brackets in there?)-ish stuff.  I'm still on the fence about=20
many details of implementing either or both.

=2D-Eric
=2D-=20
software:  a hypothetical exercise which happens to compile.
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

0
scratchcomputing
3/18/2007 10:10:10 AM
# from Mark Dootson
# on Saturday 17 March 2007 09:03 pm:

>I'm presently stuck with
>
>->MyGetControlMethod('controlname');
>->MyGetMenuMethod('menuname');
>
>which, of course, works and is I think at least better than
>$self->{controlname} or $self->{menuitemisaved}.

Well, I just put a WxPerl::MenuMaker in $self->mm and 
$self->{control_name} is simply $self->control_name.  If you then have 
clashing methods because of widget names, that's going to make trouble 
anyway, so I tend to see the "pass a string to a method" scheme as 
unjustified (and you have to error-check it.)

>I'm undecided on the named accessor thing. On the one hand I think
> that any accessors in your classes should behave in a standard way vs
> inheritance whether hard coded or added at runtime and if you can't
> achieve that you should leave it alone.

Well, Class::Accessor doesn't allow you to override the accessors.  It 
does allow you to override the get()/set() methods, but 
Class::Accessor::Fast loses that.  Class::Accessor::Classy lets you 
have it both ways (at least, as soon as I push the next version) by 
declaring a setter(sub {...});  Anyway, that's all overkill for simply 
preventing typo's when accessing child widgets, but inheriting a new() 
really rains on the parade if you're subclassing something besides the 
accessor generator.  If you're not making a specialized accessor 
generator, why subclass an accessor generator?

Nearly all of dotReader is done in Class::Accessor::Classy now, and I'm 
thoroughly enjoying the clean, declarative syntax since it basically 
serves as documentation where __PACKAGE__->mk_accessors("foo") won't.  
Also, the recent meta-data capturing means ./util/accessor_report can 
show me all of the attributes for a given class.

> On the other hand, accessors 
> for controls would be sooooo nice and you could always take the view
> that in practical terms, approach X does the job so lets go for it.

Yeah, '$self->that_button' does the job.

> Then again, would it be wise to implement your own scheme rather than
> the commonly used Class::Accessor with its known limitations /
> workarounds? I'm firmly on the fence today.

Uh, it's already implemented and requires no workarounds?  I might not 
be wise, I might be crazy, but I'm pretty sure I'm not delusional 
(yet :-D)

--Eric
-- 
"I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors."
--Ben Schneiderman
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/18/2007 10:29:18 AM
# from Mark Dootson
# on Saturday 17 March 2007 02:13 pm:

>So ... (and sorry for getting all gui designer specific) what's needed
>is a dialog designer written in perl that gets 80% of things right so
>you can fix the other 20% to meet your own needs. The thing is, once
> one has attained the level of basic competence that allows one to
> make a reasonable job of writing such a thing - one has probably lost
> a lot of the incentive to do so. I'm just going to attempt to get the
> ball rolling by shoving something out that does stuff the way I want
> it to.

Oh, I do want a dialog designer.  I just said I didn't want to talk 
about it.  But, here we go.

I don't want it to get in my way.  I also don't want XRC, and I'm not 
sure that anything XML would be a good idea when we have YAML.

What about a compile-time class generator that feeds off of a perl data 
structure?  That would get around most of the troubles with generated 
(printed) code, and possibly lead the way to something that allows 
run-time redefinition (think menu-items, but I wouldn't rule-out 
buttons, sizer layouts, etc.)  Add the ability to break individual 
class designs into separate files and you open the option to use 
something like SGI::FAM to automatically redefine the class when the 
source changes on disk (e.g. the designer could modify the running 
code.)  Now make the designer also understand this data-structure (and 
possibly use the file-alternation-monitor), and you get the two-way 
street that wxglade is so badly lacking.  This, of course assumes a 
unix-like development system (and shouldn't be enabled in typical 
deployment builds.)

Besides being slower than a dead snail on vacation in the arctic, XRC 
seems to have no way to create objects other than in sizer-order.  IMO, 
the object creation and sizer declaration should be totally separate.  
Further, the manual process of loading the individual bits and 
constantly calling GetXRCID($name) to get access to things that already 
have names is just plain painful.  Think `$class->new()` and 
`$self->$name`.  Now, doesn't that sound better?  Perl's unifying 
concept of "everything is a string" really gets lost in the Wx paradigm 
of "everything is a number".

I think it would also do well to include support for events.  AFAICT, 
XRC has nothing for this.

How about code snippets as part of the designer?  (Again, broken into 
individual files.)  I'm not sure about this yet, but it does seem to 
have some yummy smalltalk flavor.

Just think "strings are methods" and you're well on your way to being 
free of the C++ mindset which is likely at the core of most of what I 
find lacking in XRC.

--Eric
-- 
Like a lot of people, I was mathematically abused as a child.
--Paul Graham
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------

0
scratchcomputing
3/18/2007 10:51:22 AM
Eric Wilhelm <scratchcomputing@gmail.com> writes:

> # from Johan Vromans
> # on Saturday 17 March 2007 04:59 am:
>
>>I think this is an very unfortunate attitude.
>
> What!?  I'm trying to be pragmatic here.  Code generation doesn't work, 
> so I don't think it is worth discussing.

That, again, is a very unfortunate attitude. And surprising, since
your Wx::Declare is just a code generator disguised as method calls.

For me, code generation works and many of my programs contain
generated code. Writing a generator is often more fun than writing the
generated code ;-).

-- Johan

0
jvromans
3/18/2007 12:19:02 PM
--- Eric Wilhelm <scratchcomputing@gmail.com> wrote:

> # from Sergei Steshenko
> # on Saturday 17 March 2007 07:16 pm:
> 
> >I am not sure I clearly understand what it's about, but why new
> > syntax/language to describe hierarchical relationship if Perl already
> > supports hierarchical data structures ?
> 
> One word:  concisification
> 
> >my $children_array_ref = # or should it be hash ref ?
> 
> No, order matters.
> 
> >� [
> >� � { # first child
> 
> oops, we lost the order now
> 
> >� � custom_bit =>
> >� � � {
> ...
> >� � text_ctrl =>
> >� � � {
> >� � � type => 'ctrl',
> >� � � label => "", # I'm not sure about this
> >� � � style =>
> >� � � � {
> >� � � � te => MULTILINE|READONLY|DONTWRAP 
> >� � � � # these are meant to be bitwise OR'ed constants 
> >    � � } 
> 
> Yeah, but the te => 'string|string|string' means the style() function 
> can append wxTE_ to the front, so-as to Wx->"wxTE_$thing" it.
> 
> >� � � }
> >� � },
> >
> >� � { # second child
> >� � ...
> >� � }
> >� ];
> 
> >Whenever I see another language inside Perl, I'm getting really
> > nervous - another (possibly incomplete) definition, another (possibly
> > buggy) parser ...
> 
> Nope, no parser.
> 
> >Well, the original example is likely still Perl, but why a subroutine
> > where plain hierarchical data structure should suffice ?
> 
> The data structure would basically have to be array refs all the way 
> down.  Also, the style() function does some mapping.  The idea was 
> basically to make a mini-language that would add some unverbosity and 
> other conveniencification.
> 
> (The Bushism-ated words are jokes.  You should laugh now.  I'm not 
> really going to extendify the language like that.)
> 
> A sufficiently expressive data-structure would be good, but it wouldn't 
> be declarative.  The benefit of the declarative bits of code is that 
> their procedural guts can remove the need for ']]]]]]]]]]'(did I get 
> enough brackets in there?)-ish stuff.  I'm still on the fence about 
> many details of implementing either or both.
> 
> --Eric
> -- 
> software:  a hypothetical exercise which happens to compile.

I don't quite understand the ']]]]]]]]]]' part - do you think that nested
function calls are any better ?

The point of Perl data structures is that is is also (and primarily) code.

I.e. suppose you need to write something like this:

{
....
funky_array => [1, 2, 3, 5, 8 ...], # element is the some of previous two, and this way
                                    # 100 times; 
....
}
..

So, this is Perl, and there is more than one to do it, and I would do it
this way:

{
....
funky_array => do{
                 my @tmp_array;  # no name clash danger, the scope
                                 #  protects from name contention

                 my $number_of_times = 100; # I said 100 times, dodn't I ?

                 my $previous_element = 0;
                 my $element = 1;

                 while($number_of_times-- > 0)
                   {
                   $element += $previous_element;
                   push @tmp_array, $element;
                   $previous_element = $element;
                   }

                 \@tmp_array; # the array reference to be returned
                 }
};

So, the point of this example is that there should be canonical/normalized data
structure and there can be infinite number of ways to produce it.

IMO the power of Perl is anonymity - this ensures no name clashes, and the 'do'
statement is an anonymous executable/executed code block returning a value
(array reference in this case).

Define the canonical form and give user freedom to produce it - this is how
I'm writing my stuff.

....

FWIW, have a look at

http://exit1.org/Gtk2-Ex-FormFactory/

- though this is for gtk2-perl, the idea is still OK IMO.

Regards,
  Sergei.



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


 
____________________________________________________________________________________
Now that's room service!  Choose from over 150,000 hotels
in 45,000 destinations on Yahoo! Travel to find your fit.
http://farechase.yahoo.com/promo-generic-14795097

0
sergstesh
3/18/2007 9:15:02 PM
# from Sergei Steshenko
# on Sunday 18 March 2007 02:15 pm:

>funky_array =3D> [1, 2, 3, 5, 8 ...],
># element is the some of previous two,
># and this way 100 times;=20

>So, this is Perl, and there is more than one to do it, and I would do
> it this way:
>
>{
>...
>funky_array =3D> do{
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my @tmp_array; =A0# no name clash dange=
r, the scope
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0# =A0pr=
otects from name contention
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $number_of_times =3D 100; # I said 1=
00 times, dodn't
> I ?
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $previous_element =3D 0;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0my $element =3D 1;
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while($number_of_times-- > 0)
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0{
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$element +=3D $previous_element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0push @tmp_array, $element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0$previous_element =3D $element;
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\@tmp_array; # the array reference to b=
e returned
>=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
>};
>
>So, the point of this example is that there should be
> canonical/normalized data structure and there can be infinite number
> of ways to produce it.

=46ine.  But, you should be able to skim over the code in much less space. =
=20
When you want to build something based on a rolling pair of values, why=20
not use a rolling pair of values?

  ...
  funky_array =3D> do {my @p =3D (1,2);
    [1,2,map({push(@p, my $v =3D shift(@p)+$p[0]); $v} 3..100)]},
  ...

And once you know it is correct, you don't have to read it.  Of course,=20
I would put that in a method call and maybe even test that it gave the=20
correct answer.

And as far as understanding what it does.  With a little examination, it=20
is fairly clear that it doesn't do:

  ...
  funky_array =3D> [map({2**$_} 0..99)],
  ...

Thanks for helping to illustrate my point.  More code means more bugs. =20
Individual line complexity really doesn't mean much.  Bug density has=20
been shown to be roughly a constant proportion of SLOC across multiple=20
languages.

=2D-Eric
=2D-=20
perl -e 'srand; print join(" ",sort({rand() < 0.5}
  qw(sometimes it is important to be consistent)));'
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

0
scratchcomputing
3/18/2007 10:17:37 PM
--- Eric Wilhelm <scratchcomputing@gmail.com> wrote:

> # from Sergei Steshenko
> # on Sunday 18 March 2007 02:15 pm:
> 
> >funky_array => [1, 2, 3, 5, 8 ...],
> ># element is the some of previous two,
> ># and this way 100 times; 
> 
> >So, this is Perl, and there is more than one to do it, and I would do
> > it this way:
> >
> >{
> >...
> >funky_array => do{
> >� � � � � � � � �my @tmp_array; �# no name clash danger, the scope
> >� � � � � � � � � � � � � � � � �# �protects from name contention
> >
> >� � � � � � � � �my $number_of_times = 100; # I said 100 times, dodn't
> > I ?
> >
> >� � � � � � � � �my $previous_element = 0;
> >� � � � � � � � �my $element = 1;
> >
> >� � � � � � � � �while($number_of_times-- > 0)
> >� � � � � � � � � �{
> >� � � � � � � � � �$element += $previous_element;
> >� � � � � � � � � �push @tmp_array, $element;
> >� � � � � � � � � �$previous_element = $element;
> >� � � � � � � � � �}
> >
> >� � � � � � � � �\@tmp_array; # the array reference to be returned
> >� � � � � � � � �}
> >};
> >
> >So, the point of this example is that there should be
> > canonical/normalized data structure and there can be infinite number
> > of ways to produce it.
> 
> Fine.  But, you should be able to skim over the code in much less space.  
> When you want to build something based on a rolling pair of values, why 
> not use a rolling pair of values?
> 
>   ...
>   funky_array => do {my @p = (1,2);
>     [1,2,map({push(@p, my $v = shift(@p)+$p[0]); $v} 3..100)]},
>   ...

Why should I load my brain trying to understand what $p means ?

And why should help those claiming Perl is unreadable ?

And what is $v if I may ?

I prefer readable code, not a short one.

I remember a few days ago a colleague of mine was saying "'i' is current and 'j' is
previous". And the colleague had a real difficulty debugging her own code.
And I wanted to ask her "Why did you give your variables meaningless names in the
first place ?".

I wouldn't have written such a code in the first place - in my code previous is
previous and current is current.

Sorry.

--Sergei.

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



 
____________________________________________________________________________________
Need Mail bonding?
Go to the Yahoo! Mail Q&A for great tips from Yahoo! Answers users.
http://answers.yahoo.com/dir/?link=list&sid=396546091

0
sergstesh
3/18/2007 11:08:34 PM
# from Sergei Steshenko
# on Sunday 18 March 2007 04:08 pm:

>> =A0 ...
>> =A0 funky_array =3D> do {my @p =3D (1,2);
>> =A0 =A0 [1,2,map({push(@p, my $v =3D shift(@p)+$p[0]); $v} 3..100)]},
>> =A0 ...
>
>Why should I load my brain trying to understand what $p means ?
>And what is $v if I may ?

Well, one-letter variables that only appear within a closed block on two=20
lines of code never bothered me.  I prefer to think about the algorithm=20
and not whether the code *appears* to be readable.  It's encapsulated=20
by virtue of its seeming opacity.

>I prefer readable code, not a short one.

I prefer correct code.  If my subtlety eludes you, go run yours and see=20
what answer you get.  It is just a long-winded [map({2**$_} 0..99)]=20
(i.e. a doubling sequence) which is at-a-glance very readably wrong.

I really don't understand why so many people seem to think that longer=20
code is somehow better and more readable.  Have they had a readability=20
study?  Would you call a 5000-page novel "readable"?  Is a 20-hour=20
movie "watchable"?  If you're writing 10 times as much Perl as you=20
should, why not just use C?  You'll have the same number of bugs, but=20
they'll run faster :-D

A local news station once had (maybe still does have) the slogan "Clear,=20
accurate, and to-the-point."  I always thought it ironic that they=20
would use so many words to claim that they are "concise".

I'm not claiming that code should be all one-character variable names in=20
a single chain of compile-time map() statements with no carriage=20
returns (for that, you need lisp.)  Rather, code should not be any=20
longer than it needs to be.  A large part of Perl's expressiveness=20
comes from context, implied information, and concision.  There's more=20
than one way to do it, but there's a whole lot of ways to do it wrong.

Concise and correct code beats long-winded incorrect code.  Further,=20
short and incorrect code is easier to fix.  In fact, the longer code is=20
obfuscated by its shear size.  Ever heard the phrase "needle in a=20
haystack"?  For code to be readable, you have to understand what it is=20
doing.  I could use utf8 with greek characters for variable names and=20
it would make as much sense and still be correct.  We have two things=20
@p which get rotated as the new one $v arrives.  How is that more=20
complicated than your longhand variable names?  (If you haven't found=20
the bug, I think you need yet another variable to hold the new value. =20
Then it will give 1,1,1,1,1 instead of 1,2,4,8,16.  But to get=20
1,2,3,5,8,13 you have to deal with the seeding.)

So you want better variable names and comments?  Fine.  The algorithm is=20
still more clearly (and correctly) expressed in less code.

  funky_array =3D> do {
    my @pair =3D (1,2); # previous pair
    [1,2, # seed first
      map({ # roll-over the pair while calculating the next val
        push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      $new_value
    } 3..100)]
  },

Or,

  funky_array =3D> do {
	my @out =3D my @pair =3D (1,2); # seed/previous pair
	for(3..100) {
      # roll-over the pair while calculating the next value
      # I call it '$new_value' because it is new, and a value.
	  push(@pair, my $new_value =3D shift(@pair)+$pair[0]);
      push(@out, $new_value);
    }
	\@out
  },

Well, that's getting long-winded.  But, to make sure the dead horse is=20
thoroughly beaten, let me just say that you (hopefully) won't be=20
searching your codebase for bugs and skimming this e-mail in=20
=46oo::Bar.pm.  Code is going to be read/skimmed over and over and over=20
and over and over again.  You pay for the extra lines of code *all the=20
time*.  You only pay for the extra density when you're working on that=20
particular chunk.

=2D-Eric
=2D-=20
"Because understanding simplicity is complicated."
=2D-Eric Raymond
=2D--------------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------------

0
scratchcomputing
3/19/2007 12:35:02 AM
--- Eric Wilhelm <scratchcomputing@gmail.com> wrote:

> # from Sergei Steshenko
> # on Sunday 18 March 2007 04:08 pm:
> 
> >> � ...
> >> � funky_array => do {my @p = (1,2);
> >> � � [1,2,map({push(@p, my $v = shift(@p)+$p[0]); $v} 3..100)]},
> >> � ...
> >
> >Why should I load my brain trying to understand what $p means ?
> >And what is $v if I may ?
> 
> Well, one-letter variables that only appear within a closed block on two 
> lines of code never bothered me.  I prefer to think about the algorithm 
> and not whether the code *appears* to be readable.  It's encapsulated 
> by virtue of its seeming opacity.
> 
> >I prefer readable code, not a short one.
> 
> I prefer correct code.  If my subtlety eludes you, go run yours and see 
> what answer you get.  It is just a long-winded [map({2**$_} 0..99)] 
> (i.e. a doubling sequence) which is at-a-glance very readably wrong.
> 
> I really don't understand why so many people seem to think that longer 
> code is somehow better and more readable.  Have they had a readability 
> study?  Would you call a 5000-page novel "readable"?  Is a 20-hour 
> movie "watchable"?  If you're writing 10 times as much Perl as you 
> should, why not just use C?  You'll have the same number of bugs, but 
> they'll run faster :-D
> 
> A local news station once had (maybe still does have) the slogan "Clear, 
> accurate, and to-the-point."  I always thought it ironic that they 
> would use so many words to claim that they are "concise".
> 
> I'm not claiming that code should be all one-character variable names in 
> a single chain of compile-time map() statements with no carriage 
> returns (for that, you need lisp.)  Rather, code should not be any 
> longer than it needs to be.  A large part of Perl's expressiveness 
> comes from context, implied information, and concision.  There's more 
> than one way to do it, but there's a whole lot of ways to do it wrong.
> 
> Concise and correct code beats long-winded incorrect code.  Further, 
> short and incorrect code is easier to fix.  In fact, the longer code is 
> obfuscated by its shear size.  Ever heard the phrase "needle in a 
> haystack"?  For code to be readable, you have to understand what it is 
> doing.  I could use utf8 with greek characters for variable names and 
> it would make as much sense and still be correct.  We have two things 
> @p which get rotated as the new one $v arrives.  How is that more 
> complicated than your longhand variable names?  (If you haven't found 
> the bug, I think you need yet another variable to hold the new value.  
> Then it will give 1,1,1,1,1 instead of 1,2,4,8,16.  But to get 
> 1,2,3,5,8,13 you have to deal with the seeding.)
> 
> So you want better variable names and comments?  Fine.  The algorithm is 
> still more clearly (and correctly) expressed in less code.
> 
>   funky_array => do {
>     my @pair = (1,2); # previous pair
>     [1,2, # seed first
>       map({ # roll-over the pair while calculating the next val
>         push(@pair, my $new_value = shift(@pair)+$pair[0]);
>       $new_value
>     } 3..100)]
>   },
> 
> Or,
> 
>   funky_array => do {
> 	my @out = my @pair = (1,2); # seed/previous pair
> 	for(3..100) {
>       # roll-over the pair while calculating the next value
>       # I call it '$new_value' because it is new, and a value.
> 	  push(@pair, my $new_value = shift(@pair)+$pair[0]);
>       push(@out, $new_value);
>     }
> 	\@out
>   },
> 
> Well, that's getting long-winded.  But, to make sure the dead horse is 
> thoroughly beaten, let me just say that you (hopefully) won't be 
> searching your codebase for bugs and skimming this e-mail in 
> Foo::Bar.pm.  Code is going to be read/skimmed over and over and over 
> and over and over again.  You pay for the extra lines of code *all the 
> time*.  You only pay for the extra density when you're working on that 
> particular chunk.
> 
> --Eric
> -- 
> "Because understanding simplicity is complicated."
> --Eric Raymond
> ---------------------------------------------------
>     http://scratchcomputing.com
> ---------------------------------------------------
> 
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> wxperl-users mailing list
> wxperl-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wxperl-users
> 

I just reject outright the code with $p, $v, $i, $j - I admit I am too dumb
to understand it.

Sorry, I was educated that names have to be meaningful and self-explanatory,
which allows one to have self-documented coded, i.e. code needing practically
no comments, because the comments are not needed.

Everything should be obvious; comments should be needed only in places where
the code is not obvious.

Regards,
  Sergei.


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


 
____________________________________________________________________________________
The fish are biting. 
Get more visitors on your site using Yahoo! Search Marketing.
http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

0
sergstesh
3/19/2007 1:41:03 AM
Reply:

Similar Artilces:

[wxperl-users] wxPerl Wiki => wxPerl Kwiki
Hello all, Once upon a time I installed a Wiki, called it the wxPerl Wiki and didn't look at it anymore. I noticed that only a few people use it, it's been hacked a few times, and to make it work, at least yours truly should put more time and effort in it. This morning I started installing Kwiki, which is a far better Wiki platform than the Wiki that was installed. Apart from the UserPreferences page (working on it), everything works as it should. However, the data people entered in the old Wiki can't be converted to Kwiki automatically. Therefore I need your ...

[wxperl-users] [ wxperl-Bugs-1237847 ] wxPerl does not build with wxUniversal
Bugs item #1237847, was opened at 2005-07-13 23:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115655&aid=1237847&group_id=15655 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Mattia Barbon (mbarbon) Assigned to: Nobody/Anonymous (nobody) Summary: wxPerl does...

Fwd: wxPerl on the Mac; was: [wxperl-users] Re: problems with wxPerl
>To: Jouke Visser <jouke@pvoice.org>, wxperl-users@lists.sourceforge.net >From: Christian Jaeger <christian.jaeger@sl.ethz.ch> >Subject: wxPerl on the Mac; was: [wxperl-users] Re: problems with wxPerl >Date: Sun, 30 Sep 2001 23:08:19 +0100 > >Hello, > >I'm crossposting this reply to the macosx-perl mailing list because >there is some interest, too. Actually I forgot to put the macosx-perl adress on it. >At 14:02 Uhr +0200 24.9.2001, Jouke Visser wrote: >>I wondered if anyone yet tried to compile wxPerl on a Mac. If not, I'...

[wxperl-users] [ wxperl-Bugs-588884 ] wxperl will not compile
Bugs item #588884, was opened at 2002-07-30 17:13 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=115655&aid=588884&group_id=15655 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dan Stahlke (danstahlke) Assigned to: Nobody/Anonymous (nobody) Summary: wxperl will not compile Initial Comment: I cannot get the wxPerl module to compile. It breaks with this message: c++ -c -I/usr/local/lib/wx/include/gtk-2.3 -I/usr/local/include -I. -fno-rtti -fno-exceptions -O2 -DVERSION=\0.10\ -DXS_VERSION=\...

[wxperl-users] WxPerl Samples..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am currently using WxWin 2.26 with c++, and I am an occassional perl programmer. I would like to know if anyone has some WxPerl samples handy, I downloaded the recent distribution and installed it with PPM. I downloaded the .chm document file supplied at the ftp site for wxperl, and searched for "perl" in the document, and found only one hit?!? Would just like to see some sample script to get me started.. cya... Amanjit Gill (amanjit.gill@gmx.de) MSN Messenger (amanjit_gill@hotmail.com) "Just do it. ...

[wxperl-users] wxPerl constants
Hi, Newbie question - how does one suck in all the wxPerl constats into your code ie stulff like wx_OK etc etc. Geoff -- View this message in context: http://www.nabble.com/wxPerl-constants-t1177761.html#a3098302 Sent from the wxperl-users forum at Nabble.com. On Feb 23, 2006, at 1:47 PM, Geoff M wrote: > > Hi, > > Newbie question - how does one suck in all the wxPerl constats into > your > code ie stulff like wx_OK etc etc. > > Geoff Name all of the constants your package needs in the "use statement. E.g.: use Wx qw(wxHORIZONTA...

[wxperl-users] wxPerl overview
dear monks and mongers in the wx docu is a page about wxpython. see at: http://proton-ce.sourceforge.net/rc/wxwindows/docs/html/wx/wx500.htm#wxpython but nothing about wxperl. im about to change that. I askby this way you, all my precious brothers and sisters, for any suggestions and hints. my half ready version is online at http://proton-ce.sourceforge.net/rc/wxperl/wx500.htm. i know the chapter about other gui isnt ready, maybe has someone more experience with PerlQT or PerTK to prevent that i blame myself. and the text for the hello wxperl, .... im on it the linklist to t...

[wxperl-users] wxPerl demo
Hi all, I am going to split the demo distribution from wxPerl, make it installable from CPAN and include most of what is currently under samples/ inside the demo. As a start I created the wxDemo module in CVS, which is a slightly improved version of the current demo, plus code extracted from the (horrible) control sample. In the next wxPerl release, I will remove the demo/ subdirectory and any samples I was able to assimilate in the demo. In the future I plan to change the look of the demo to be somewhat like the 'widgets' wxWidgets sample: on the right of the ...

[wxperl-users] wxPerl wxGetPasswrodFromUser
This is a multi-part message in MIME format. ------=_NextPart_000_0130_01C3A2D0.47712300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable please, what is the corresponding wxperl function (and how to use) to = the 'C' wxGetPasswordFromUser? I did not find doc for that. my env : wxperl 0.15 and ActiveState 5.6.1 on win XP. thanks in advance, ulisses ------=_NextPart_000_0130_01C3A2D0.47712300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable &l...

[wxperl-users] wxPerl::Styles
Hi all, Here's a style shortcut package to complement wxPerl::Constructors http://scratchcomputing.com/svn/wxPerl-Styles/trunk/ I realize that style('hscroll', te => 'process_enter|multiline') isn't much shorter than (style => Wx::wxHSCROLL()|Wx::wxTE_PROCESS_ENTER()| Wx::wxTE_MULTILINE()), but shortness is only an interim goal. By processing the constants as strings, I'm hoping to enable a better XRC-like thing. In the meantime, it's shorter enough that I think I can get all of the style onto one line more often than not. Thoughts...

[wxperl-users] wxperl on MacOSX
Hello I'm happy to find today the announcement of a wxwindows-perl interface in www.perl.com's newsletter. It could just be what I'm looking for: some perl gui for MacOS (9/)X. Tough I'm a bit in doubt whether wxperl will work on the mac (primarily MacOSX, MacOS9 would be cool too)? I want to create a rather simple gui: create popup dialogs on top of the desktop (maybe floating windows). It's for a networked message application. It should pop up a window if it receives a message. I've been thinking about porting the perl Mac::* toolbox modules to ...

[wxperl-users] wxperl on solaris ?
I desperately need a perl GUI that runs on solaris/linux/windows. So I found wxperl that seems very nice, and runs pretty well on windows and linux. But I can't manage to make it works under solaris2.6, with gtk1.2.10, wxGtk-2.4, perl 5.6.1 and gcc2.95.2. the compilation process seems successful, but when I try to run any wxperl script, I get the following message : ClassInfo initialization failed 'wxSashWindow' at /nfs/aletheia/packages/all/perl/lib/5.6.1/sun4-solaris2.6/DynaLoader.pm line 206. Compilation failed in require at -e line 1. BEGIN failed--compila...

[wxperl-users] wxPerl documentation
Hi, I'm new to wxPerl and I'm finding that I fall into the cracks between wxPerl and wxWindows. I'm not sure what documentation to follow. Specifically, at the moment I'm trying to create a ListBox. I appear to have succeeded, that is, I don't get any errors, but I also don't see a box. How do I give it a position, size, etc? The syntax I'm using is not what's specified in the wxWindows online document (more like Perl), but I don't want to start guessing. I have <CODE> my $list1 = Wx::ListBox->new(); # make a list box, I hope...

[wxperl-users] wxPerl Wiki
The wxPerl Wiki I mentioned before has more or less been set up. The current url is http://213.84.151.206/cgi-wxperl/view.pl/FrontPage , which will become http://wxperl.pvoice.org/cgi-wxperl/view.pl/FrontPage in a few days (after the dns change has been propagated throughout the world). Of course the Wiki is empty right now, but I'll be starting to put things on it, and hope a lot of you will do the same. Jouke ...

Web resources about - [wxperl-users] your wxPerl wishlist? - perl.wxperl.users

O'Reilly Open Source Convention 2007 • July 23-27, 2007 • Portland, Oregon
O'Reilly Open Source Convention 2007 - July 23-27, 2007 - Portland, Oregon

Resources last updated: 12/3/2015 3:32:50 PM