RE: [perl-win32-gui-hackers] -style deprecated

[Jeremy White <jez_white@ho...>]

>I get the message. What should be used? Looked at all the documentation 
>that I
>have (including my new jeb-doc) and can't find what the alternative is. 
>Sigh.

see:

http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-options

popstyle, pushstyle is what you want.


>On another note, while looking for -style I looked at GUI.xs.
>
>Being loath to comment:
>1.  GUI.xs uses a conditional ladder to perform a search.
>2.  On success, GUI.xs executes code in the conditional block.
>
>It occurs to me that there are two operations that need to be performed; 1)
>search, 2) some action based on the search. The current approach is the 
>same
>type of approach that was used in GUI-Constants.cpp. That was changed to a
>hash, I wonder if this can also be changed (and yeh, I do know about "it's 
>not
>used too often", but the best code is the one to be desired, yes?).
>
>The search consists of two parts:
>   search, action

Personally, I'm a speed freak - if something can be made faster, I'm all for 
it. In my own apps, I'll even go as far as making the code harder to 
maintain:) However, there is always functions that aren't worth optimising 
because either they are used during initialisation or they are called 
infrequently during runtime. I don't know if this is the case in what you've 
highlighted. Yes, in principle the best code should be always used, but 
would it be worth your time "fixing" this area when it's not broken? I would 
say if there is little benefit in terms of performance, your talents are 
better used elsewhere.

My intent is not to discourage you, on the contrary, you clearly know what 
you are doing, and you will be a great asset to the Win32-GUI project. Your 
suggestion may have merit, but you would need to do some testing to see how 
long Win32-GUI spends in the area's that you think could be optimised. If 
you create some code to do this, and you need other people to run it against 
their applications, I'm sure people would help gather the statistics.

Cheers,

jez.

[perl-win32-gui-hackers] -style deprecated

[Arthur Schwarz <aschwarz1309@ve...>]

I get the message. What should be used? Looked at all the documentation that I
have (including my new jeb-doc) and can't find what the alternative is. Sigh.

On another note, while looking for -style I looked at GUI.xs. 

Being loath to comment:
1.  GUI.xs uses a conditional ladder to perform a search.
2.  On success, GUI.xs executes code in the conditional block.

It occurs to me that there are two operations that need to be performed; 1)
search, 2) some action based on the search. The current approach is the same
type of approach that was used in GUI-Constants.cpp. That was changed to a
hash, I wonder if this can also be changed (and yeh, I do know about "it's not
used too often", but the best code is the one to be desired, yes?).

The search consists of two parts:
  search, action

A data structure (in C/C++) can be constructed to accomodate this,
to wit:

    typedef struct SEARCH {
              char * Str;
              <type> Action;
            };

    SEARCH  Table[] = { { "string", <attributes> }
                      , { "string", <attributes> }
                      , ...
                      };

    where <type> can be any collection of things you might
    like done. For example:

    <type> could be: typedef bool (*func)(<data type> <data);

    yielding pointers to functions, or it could be an int
    or an enumeration type, yielding a switch statement, 
    or ....
 
    In a similar way the <attributes> can be a single 
    attribute (which is what seems to be done now) or
    some complex list of attributes.

    And the search code could be something like:

    if ( Idx = Search(<input string>) > -1 ) {
      Table[Idx].Func(<data>);   // or
      switch Table[Idx].Swtch;   // or something else
    }

    the choice of Search is left open and need not be
    a function (as shown here).

The sole advantage (that I can see) is that the conditional ladder is made a
search through a data structure. The data structure can be altered but the
Search and action code need not be changed, since the search is independent of
data content and the action is captured as part of the data. And, to some
limited extent, it's faster.

On another note, have you thought about reworking your debug statements? What I
usually do is one of:

# if #defined DEBUG_FLAG
  #define  DEBUG( stmt ) stmt
# else
  #define  DEBUG( stmt )
# endif

  and in use I do something like:

  DEBUG( fprintf (...) ); )

  or in more complex cases, something like:

  DEBUG({ really complex debug code; })

  which all disappears if the flag is not defined. I think
  the code looks cleaner than:

# if defined DEBUG_FLAG
   code;
# endif

Since I normally like to be able interactively turn debugging on and off during
development (and to do it selectively based on some ungodly reasoning), I often
augment the above to something like:

# if #defined DEBUG_FLAG
  #define  DEBUG( flag, stmt ) if ( flag ) stmt
# else
  #define  DEBUG( stmt )
# endif

  with an example of:

  DEBUG( flag, fprintf(); )  // or
  DEBUG( flag, {really complex stuff})

  And if the flag is not a const then it can be turned
  on or off, and if it is a const false, the compiler
  should remove the code.


Whew. Another mind buried in ego.

art

    
    

RE: [perl-win32-gui-hackers] -style deprecated

[Jeremy White <jez_white@ho...>]

>I get the message. What should be used? Looked at all the documentation 
>that I
>have (including my new jeb-doc) and can't find what the alternative is. 
>Sigh.

see:

http://perl-win32-gui.sourceforge.net/cgi-bin/docs.cgi?doc=reference-options

popstyle, pushstyle is what you want.


>On another note, while looking for -style I looked at GUI.xs.
>
>Being loath to comment:
>1.  GUI.xs uses a conditional ladder to perform a search.
>2.  On success, GUI.xs executes code in the conditional block.
>
>It occurs to me that there are two operations that need to be performed; 1)
>search, 2) some action based on the search. The current approach is the 
>same
>type of approach that was used in GUI-Constants.cpp. That was changed to a
>hash, I wonder if this can also be changed (and yeh, I do know about "it's 
>not
>used too often", but the best code is the one to be desired, yes?).
>
>The search consists of two parts:
>   search, action

Personally, I'm a speed freak - if something can be made faster, I'm all for 
it. In my own apps, I'll even go as far as making the code harder to 
maintain:) However, there is always functions that aren't worth optimising 
because either they are used during initialisation or they are called 
infrequently during runtime. I don't know if this is the case in what you've 
highlighted. Yes, in principle the best code should be always used, but 
would it be worth your time "fixing" this area when it's not broken? I would 
say if there is little benefit in terms of performance, your talents are 
better used elsewhere.

My intent is not to discourage you, on the contrary, you clearly know what 
you are doing, and you will be a great asset to the Win32-GUI project. Your 
suggestion may have merit, but you would need to do some testing to see how 
long Win32-GUI spends in the area's that you think could be optimised. If 
you create some code to do this, and you need other people to run it against 
their applications, I'm sure people would help gather the statistics.

Cheers,

jez.

RE: [perl-win32-gui-hackers] -style deprecated

[Arthur Schwarz <aschwarz1309@ve...>]

> >On another note, while looking for -style I looked at GUI.xs.
> >
> >Being loath to comment:
> >1.  GUI.xs uses a conditional ladder to perform a search.
> >2.  On success, GUI.xs executes code in the conditional block.
> >
> >It occurs to me that there are two operations that need to be performed; 1)
> >search, 2) some action based on the search. The current approach is the 
> >same
...

> However, there is always functions that aren't worth optimising 
> because either they are used during initialisation or they are called 
> infrequently during runtime. I don't know if this is the case in what you've 
> highlighted. Yes, in principle the best code should be always used, but 
> would it be worth your time "fixing" this area when it's not broken? I would 
> say if there is little benefit in terms of performance, your talents are 
> better used elsewhere.

The primary issue is maintenance and ease of understanding. In this case, speed
is increased and space is decreased.

The rationale is that since the basic code doesn't change (search and decision)
future changes are limited to placement of data within a data structure.
Maintaining the current approach requires the generation of code, for the
search, and the placement of the code within a conditional ladder, and the
generation of code for the action to be performed or the reuse of existing
code. Software must be tested and revalidated for new code, search or action.
What the proposed change does is to remove design decisions for the search
phase and at the same time remove any requirement for retesting the search, and
to leave intact decisions and testing related to the action. If an action is
reused, it presumably need not go through any rigorous testing for a reuse. If
a new action is developed, it must be tested.

In a minimalistic sense, all that has been done is to convert an increase in
code to an increase in a data structure and to reuse code. Of more global
scope, with the existing mechanization as the number of entries grows, the
amount of code grows. Even though the code is well organized and easy to
understand, at some stage it becomes almost intractable to maintain because of
its size. 

My motivation is to reduce maintainence, increase clarity, and if possible,
increase the speed of execution and decrease the memory footprint.

art

RE: [perl-win32-gui-hackers] -style deprecated

[Jeremy White <jez_white@ho...>]

>The primary issue is maintenance and ease of understanding. In this case, 
>speed
>is increased and space is decreased.

[snip]

>My motivation is to reduce maintainence, increase clarity, and if possible,
>increase the speed of execution and decrease the memory footprint.

All worthwhile sentiments, and from a macro viewpoint I do agree. I guess 
I'm coming from the "if it isn't broke, don't fix it" mentality of the 
commercial world - which isn't exactly applicable here:)

Cheers,

jez.