OpenEuphoria

2. Re: Keywords and Namesapces

• Posted by mattlewis (admin) Oct 03, 2011
• 40813 views

I think that wxEuphoria should ideally be split up (originally, it was!). In fact, I started doing this at one point. There are several issues with doing so:

• Backwards compatibility
• Lots of work

Currently, it's fairly simple to use wxEuphoria. There's a single include file. There are a few drawbacks, too. It takes a little longer to parse and load, since it always loads everything. Also, the naming convention can be cumbersome. Since the library that's being wrapped (wxWidgets) is object oriented, you can have lots of methods with the same name in different classes. wxEuphoria has to disambiguate them "the C way," which is to say, by making the names bigger to include the type of object or something.

Euphoria doesn't have classes like C++ does, but we do have namespaces, and it would be relatively easy to separate the wxEuphoria wrappers this way, so that you could have lots of set_text routines that could be easily disambiguated via namespaces.

The namespace route is the way we decided to go with the euphoria standard library. From before 4.0, there were some routines that already used a prefix (e.g., the old database.e, now std/eds.e that uses the db_ prefix). You'll note that there are some routines in the std library that have the same names. We'd have to update these with the prefixes.

But this leads to another issue. As new libraries are written, we'd likely have additional collisions. Now you'd end up with some routines that were prefixed, and some that weren't. This, IMHO, would be very confusing. Ultimately, we decided that new development would use the namespace approach, as it is relatively clean and extensible.

The standard library is a lot bigger than it used to be. The namespaces help make it a lot more manageable.

Matt

4. Re: Keywords and Namesapces

• Posted by Vinoba Oct 03, 2011
• 40804 views

"As new libraries are written, we'd likely have additional collisions." If we can use some low level software such as Euphoria, to scan the functions and look for key word and similar conflicts, the developer writing "new libraries" can avoid 110% of the time.

Addressing the issue of long names and 1600 functions, it is a relatively easy matter to condense to about 600 functions or even less. Where we have in wxEuphora: long_name_function_to_do_something(atom wind, sequence xyz)
long_name_function_to_do_nextthing(atom wind, sequence xyz)
long_name_function_to_do_goodthing(atom wind, sequence xyz)
long_name_function_to_do_specialthing(atom wind, sequence xyz)
long_name_function_to_do_uniquething(atom wind, sequence xyz)

we can change it to
long_name_function_to_do_everything(atom wind, sequence xyz, integer thingnumber)

thingnumber: 1 = something, 2=nextthing, 3=goodthing, 4=specialthing, 5=uniquething

A simple Euphoria routine in the wxeud.e can take care of these 5 alternative branches of one function and connect to the appropriate 5 C routines.

6. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Oct 04, 2011
• 40726 views

I just had to reply to this.

8. Re: Keywords and Namesapces

• Posted by mattlewis (admin) Oct 04, 2011
• 40731 views

That creates code that's slower, more difficult to maintain and harder to use.

Matt

10. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Oct 04, 2011
• 40741 views

It has precedents though. A lot of OOP libraries for Euphoria (llamagtk being one of them) do something like this where the real method that gets called depends on the type of the object.

I wonder what that says about OOP?

12. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Oct 04, 2011
• 40685 views

This seems like the Right Thing(tm) to do.

14. Re: Keywords and Namesapces

• Posted by petelomax Oct 07, 2011
• 40598 views

Just so you know, on an x86 chip that's very bad indeed. Apart from the fact it only works for contiguous ranges, inc and dec generate a "partial flags stall", which cmp a,1 etc do not. According to Agner Fog, anyway.

Regards, Pete

16. Re: Keywords and Namesapces

• Posted by petelomax Oct 08, 2011
• 40522 views

I wasn't saying it does not work, I was saying it is unnecessarily slow.

A quick experiment (this is Phix inline assembly):

atom t0,t1,t2 
 t0 = time() 
constant LIM=1000000000 
for i=1 to LIM do 
    #ilasm{mov_eax_mem32,%isVar,0,0,i, 
           cmp_eax_imm8,1, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,2, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,3, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,4, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,5, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,6, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,7, 
           jz_rel32,%isJmp,0,0,:l1, 
           cmp_eax_imm8,8, 
           jz_rel32,%isJmp,0,0,:l1, 
        ::l1 } 
end for 
t1 = time() 
for i=1 to LIM do 
    #ilasm{mov_eax_mem32,%isVar,0,0,i, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
           dec_eax, 
           jz_rel32,%isJmp,0,0,:l1, 
        ::l1 } 
end for 
t2 = time() 
printf(1,"cmp:%f, dec:%f\n",{t1-t0,t2-t1}) 
if getc(0) then end if 

Result is cmp:6s, dec: 8s, so the cmp does it in 75% of the time dec does. If you're really interested in finding out why, I'll have to refer you to Agner Fog.

Regards, Pete

18. Re: Keywords and Namesapces

• Posted by Vinoba Oct 09, 2011
• 40460 views

We have digressed from the main thrust of my argument. An extra parameter is not particularly time consuming nor difficult to implement. In Windows programming, most of the time the waiting is done by Bill Gates, not by me the programmer. Same philosophy applies to Windows under Limux and Mac, whatever you call it.

Here I have taken actual functions in wxEuphoria in CONTROL.HTML and changed to reflect what can be done.

-- New function 
-- 
client_transfer ( atom window , atom x , atom y , integer direction ) 
--(Link: #CLIENT_TRANSFER) 
-- integer direction = 1:  client_to_window , -1:  screen_to_client, 0:  move  
-- 
-- the following could be deprecated 
-- client_to_screen (Link: #CLIENT_TO_SCREEN)( atom window, atom x, atom y ) 
-- screen_to_client (Link: #SCREEN_TO_CLIENT)( atom window, atom x, atom y )    
-- move (Link: #MOVE)( atom win, integer x, integer y )  

The following illustrates even further saving in the number of functions that a programmer has to struggle with.

-- New function 
get_winitems ( atom window , integer item ) 
--(Link: #GET_WINITEMS) 
-- integer item = 1: children,  2:  parent, 3: rectangle,  
-- integer item 4: set focus, - 1:  ?is_visible , 0:  desktop window  
--   
-- For get_desktop_window, one would ignore the atom window parameter in Euphria,  
-- before invoking the appropriate wxwidget dll item. 
--  
--  
-- the following could be deprecated 
-- get_children (Link: #GET_CHILDREN)( atom window )    
-- get_parent (Link: #GET_PARENT)( atom window )    
-- get_rect (Link: #GET_RECT)( atom win )    
-- is_visible (Link: #IS_VISIBLE)( atom window )  
-- set_focus (Link: #SET_FOCU)( atom window )    
-- get_desktop_window (Link: #GET_DESKTOP_WINDOW)()    
 

In the above examples, the time taken e.g. for client_to_screen or for get_rect in the second example, is far in excess of the extra time required for analysing (either in Euphoria or Assempler or C) integer direction and integer item respectively.

20. Re: Keywords and Namesapces

• Posted by Vinoba Oct 09, 2011
• 40426 views

The main purpose of a programming language is to enable creation of a software that can be used to do repetitive tasks efficiently and fast. In this equation, the time spent by a programmer is colossally higher than the time taken by the final program to execute. THEREFORE, IT is both justifiable and IMPARATIVE, that in order to ease the task of programmer, you (u.e. the creator of language) give him a reasonable number of functions without cluttering him with nearly identical functions that he has to constantly look at a manual to find.

  file_access( fileid, access_type, otherdata .. ) 
-- access_type: 1 -> Open a file 
-- access_type: 2 -> Close a file 
-- access_type: 3 -> Read from a file 
-- access_type: 4 -> Write to a file 

There is no need to carry my suggestion to an extreme to prove me wrong.
Quite simply 1600 functions in the wxEuphoria are, in my opinion, far in excess of what they should and could be and would prevent people from using it.
For my own needs, I am already using condensed versions as illustrated by me above and teaching those rather than the 6-8 variations of the same, and students are taking to Windows programming nicely. Real life activities are full of such condensations. Human brain can catalog it better than remembering different names.

22. Re: Keywords and Namesapces

• Posted by DerekParnell (admin) Oct 09, 2011
• 40446 views

Agreed.

24. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Oct 09, 2011
• 40380 views

A non sequitur. At issue is not the language, but wxEuphoria - a set of wrappers for a library written in a different language.

Each of these functions represents one function in wxWidgets.

The implication is that the functions in wxWidgets are far in excess of what they should and could be and would prevent people from using it.

Or perhaps you meant to say that having all these functions in a single namespace is the problem, whereas breaking it up as wxWidgets does by class would solve the problem. If this is the case, then I think we have universal agreement that the best thing to do is to break wxEuphoria into namespaces.

Since that's such a big effort, I'm sure the wxEuphoria developers would be happ to accept patches for this.

Is this really condensing anything? You'd have to remember the name of the function as well as the name of the parameter.

You'd end up with just as many constants (1600 of them at least), unless we're reusing the same constant names for different functions.

Like

display ( TIME, ... ) -- display the current time 
get ( TIME, ...) -- get the current time 

I'm tempted to say that the Windows API is a good example of a real life API that is not condensed yet widely used. Then again, that API is not really a good example of how to do anything. Horrible naming standard. (What's with all those Ex functions?)

Where are you teaching, btw? I'm curious to see what classrooms are using Euphoria.

26. Re: Keywords and Namesapces

• Posted by Vinoba Oct 10, 2011
• 40333 views

Yes it is, when you can have a tool tip hovering on focus to the new integer parameter as you program - the post-grad student who pointed this out in answer to the similarly raised objections, is the person who suggested the changes in the first place.

We have a separate slate of "system variables" - these are not constants married to a particular namespace but predefined values which are frequently used - more like what you call Global Constants. These are available as click and insert just as all the function names and the user defined variables names are - no chance of misspelt words - period.

I agree. We get RoundAllTheNonReadableMumboJumbo and simply use standard English language understandable phrases as function names and variable names (allowing spaces) to convey what we are programming, which makes comments unnecessary and we also allow comments intermingled with code to make one simple English sentence which is both code and comment.

I use Kenneth Iverson as an example of a great computing Guru, and his work (APL) describing Niladic, Monadic, and Dyadic functions with or without result as a background to introducing "multi-adic" concept (as seen in most of the C plus functions), doing way with the necessity of placement of right and left arguments, but keeping his goal of pipelining, i.e. of using the result of the last execution as one argument to the next function to be executed (3 + 7 / 2 * 15) applying the concept to all the functions of a language and doing away with "Procedures". The whole condensing issue came up when somebody suggested using the concept as used in APL circle (o) functions (i.e. trigonometric functios) where 1,2,3,4,5 etc left arguments are used to denote different trigonometric functions. He said we could use the same concept into condensing wxEuphoria, which was at the time before us as an illustration of what not to do when creating a set of functions.
Incidentally, APL had the Namespace concept because we always used a Workspace as a whole with its constituents as files, functions, variables, etc. We are extending that concept laterally into the multiple Workspaces in a Network.
I use Harbour (nee Clipper), FreeBasic, Xbasic, Powerbasic, Euphoria, Lua, APL, MySQL etc as teaching tools to teach what different people come up with when creating functions, language syntax etc and how languages, particularly scripting languages evolve. The next phase will be using the newer languages examples, which I may or may not teach. Instead of computerese, I use a lot of English language colloquialism in my expression. I hope I have explained something about what and why of things. My postgrad class (which is more like a discussion group) understands me!

28. Re: Keywords and Namesapces

• Posted by Vinoba Oct 10, 2011
• 40331 views

Auto completion in fact gives more headaches. We are already way ahead of this feature. Similar looking (at first) long names are a headache too. 1 = ABC, 2=CDE, 3=FGH, etc is more readable in a tooltip, which has to be small.

An IDE that allows for NO mispelt words and instant access to the System functions as well as newly created ones by the programmer and system variables and newly created variables - all without a single mistake or even a chance of mistake, an IDE that will not allow you to proceed when you have used a wrong type in a parameter, an IDE that will allow all these and more is an elusive often bragged about feature and we already have it.
We have a problem with classifying a lot of functions. You must realize by now that the wcEuphoria library would be adjuvant to other libraries in a fully function multi-faceted language and just as you and I abhor having to go through 5-6 level of menu to get at the item you are looking to click, so do we in our efforts to give the programmer the facility of access to EVERYTHING with as few a clicks as possible. And one has to remember, that the programmer is going to look to using about 100-200 functions and similar number of variables (and Constants) in a typical medium sized effort. The fewer the number of clicks, the better
Anyway that is the thrust of my teaching and our joint efforts and so far the students who are really colleagues, love it.

30. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Oct 10, 2011
• 40315 views

How so? (How far ahead are you?)

Agreed, but this is easy to remedy - delete the shared prefix from the tooltip.

An IDE that allows for NO mispelt words and instant access to the System functions as well as newly created ones by the programmer and system variables and newly created variables - all without a single mistake or even a chance of mistake, an IDE that will not allow you to proceed when you have used a wrong type in a parameter, an IDE that will allow all these and more is an elusive often bragged about feature and we already have it.
[/quote]

This sounds more like a bad commercial advertisement than something that would be taught in a postgrad classroom or seminar.

I believe Matt admitted that this was a real problem with wxEuphoria, but namespaces would solve this.

Clicks? As in mouse clicks? When programming, one typically has to type. (Only programming language that I can think of that was primarily mouse driven was LEGO Mindstorms. That was one strange language.)

In any case, I'm not seeing a benefit in using enums here over using namespaces - or even prefixes. A properly designed IDE can use tooltips with namespaces / prefixes requiring only a single mouse click.

This entire IDE-based argument is looking like one really long non sequitur.

I'm curious. You hint at being a professor (or at least a researcher or postgrad student) at a university - yet you won't identify which university you are from.

Additionally, you log onto these forums using Sympatico HSE rather than from your university's internet connection. If your goal is to prevent anyone from being able to independently verify your university affiliation, you are doing a very good job of it. I must say, however, that this goal seems very unusual for an academic professor or researcher - if you don't give your name, you don't get the fame, which generally translates into less funding.

32. Re: Keywords and Namesapces

• Posted by Vinoba Oct 10, 2011
• 40335 views

I will not bother to answer most of his comments as we are very far apart in our thinking and approach. However, i will try and answer this comment.
Matt Lewis said: "When programming, one typically has to type."
That is the crux of my mention of IDE, that types for you. You rejected it outright without thinking about it and without thinking about how our first conversations started here (Recall Unicode).
If you have gone through the intricacies of typing in different languages, if you have done real work with Unicode as applied to all languages INCLUDING languages FROM "EAST OF SUEZ" a mental and physical barrier which seems to baffle most Westerners and obstruct their thinking, then only would you realize the beauty of my statement ""When programming, one does not have to necessarily type everything or even most of the things in the program." The IDE we are using was written in HLA (High Level Assembler) two years ago in another class by another professor (i.e. under his direction). Last year we extended it somewhat for Unicode. This year's group is discussing in depth scripting and various techniques, BUT IN ALL DISCUSSIONS, IT IS MY DIRECTION to them that they do not forget the united nations of the Languages of the world.
As to advertising a commercial product, the IDE we have is NOT for sale and is NOT a commercially available product. I was hoping to get to use wxEuphoria to see if I can bring the IDE to a little more understandable level to the newer group of programmers.
As to the adverse comments on APL, long before the rest of the programming world had even dreamt about these things, APL had
1. Complete array usage (3 7 12 + 14 2 8). Applied also to 2 and 3 dimensional matrix. Yes I know Euphoria has it, because the original author of Euphoria was APL trained. I am talking about the late 70's.
2. The symbols used were a direct result of the need to execute more functions with the limited amount of ANSI character set.
3. The unique simplicity of line interpretation (right to left) without priorities. Even to this day, I have difficulty remembering precedence, because I am jumping between too many languages. In APL I did not have to remember priorities as there was only one -RIGHT TO LEFT.
4. Workspaces, a much later invention is Namespaces, encompassed a given set of files, functions and variables. Namespaces have not yet reached that level of sophistication.
5. Complete flexibility in the use and reuse of names for variables, e.g.
AA is assigned a single number and next line it can be assigned an array of literals.
Many of the modern day programmers do not like it - it is a matter of what format you are used to.

However much people promote C plus and F sharp, even Microsoft is sticking with Old is Gold and Visual Basic remains a good and solid foundation, and their other more elaborate products can use Visual basic addons.

As far as I am concerned my input on this subject and particularly about wxEuphora functions is over. I have had good enough input from you all, and realize that you all like the 1600 functions and I like the 600 functions my team has devised. The team is already talking about moving to Nokia's QT (for examples, etc in the same way as wxWidgets/wxEuphoria now ) and there is an equal force within the system asking them to stay with Randy Hyde's HLA and extend it. I think I am going to ask the class to look at Harbour with MiniGUI or with QT to study the variety of approaches.

Please be assured that I am NOT promoting any commercial product - I don't have one, not planning on one, and not prepared for one.
Thank you all for allowing me the use of this forum.

34. Re: Keywords and Namesapces

• Posted by Vinoba Oct 10, 2011
• 40265 views

I made a suggestion which was not properly tried by me. Nobody in Euphoria was willing even to look at it. The answer from Matt way up in this thread confirms what I just said.
I then tried it with help of my "students" and of course, it works. In fact, you and others have not said it would not work.
Even a bit later when I gave a concrete example of 3 and 5 functions in Control.html changed, I was hoping for any enlightened better thought out method from you people. You all were negative about the whole idea of changes. In the meantime, the team here worked and produced the altered functions and we are using those against the old IDE. I have ALREADY SHELVED the idea of converting the IDE to wxWidgets of wxEuphoria. To us it was/is a learning/teaching exercise. Even if I had had a positive response from Matt, I would have let him and his team develop the alternative. The main idea however, was that you people might have had better solution or method of condensing to even lesser number of functions.
No product or software developed by us is ever made available to the General public or for commercial use. That is an inflexible rule of the Institution. So many people are involved in developing that one can't even give proper credits in the commercial sense.
BTW, the use of the word C plus was dictated by the quirks of your forum software which puts an underline after the real plus sign. I hastily changed from the arithmetic plus sign to the word plus. I did not think that at the level we are talking you would consider a fault on my part or lack of knowledge of that sophisticated world of modern day programmer with C plus plus plus plus plus plus to C sharp sharp sharp sharpest to F sharp sharp sharp sharpest. Next thing you might bring up is dot net and Microsoft's CLI. Another professor is working with the same team in that area - it is somebody else's baby, not mine and am glad it is not mine, because I dislike most things Microsoft.
Happy programming with Euphoria and wxEuphoria.

36. Re: Keywords and Namesapces

• Posted by Vinoba Oct 10, 2011
• 40291 views

APL gives access to about 100 powerful functions using either one keyboard key or three keys (key + backspace + another key). It gives another 100 function or so, with a single key character called Quad character followed by English language verb.
I should have said "gave" access.
The current free interpreted only hobby level APL gives the full APL character set which is staring in front of you for ONE click
http://www.nars2000.org/
Unfortunately it lacks file functions, so it is mostly useless for business level programming or even teaching. I have toyed with the idea of my class connecting some file access DLL to it, and the source code is there to play with, but I have not taken that route yet. APL Plus has a dot net version built on top of CLI which is a full professional version, which I have not used lately. It has full Windows interface and has full 16 bit LE Unicode (like Microsoft's internal). It is pretty expensive to buy. I have lived with APL ridicule (and most APLers have lived through it) ad infinatum from people who have never used APL.
I am not here advocating APL. Just as you use words like BASIC like or better than BASIC, I am quoting about the facilities in another language as something I look at. Obviously I am using some of Euphoria and wxEuphoria instead of APL plus in my teaching, otherwise I would not be in this forum.
wxEuphoria is your baby and you can improve and modify it in your way. It does not mean that others may not give suggestions to you. And you always have had and have the full right to implement or reject those suggestions.
I am going to switch to Harbour with MiniGUI and with QT because it gives a whole new angle to programming and Harbour is now 32/64 bit and uses GCC compiler. I will also touch Excel and/or Open Office Spreadsheet at that time (time permitting). Somebody else is also going to teach Microsoft Access and possibly SQL so it will add a different level of understanding for the students.

38. Re: Keywords and Namesapces

• Posted by Vinoba Nov 16, 2011
• 39189 views

Since somebody has bothered to look at this thread again, I am posting one third of one on Matt's
WXRICHTEXTCTRL1.TXT

that one of the students converted. Notice the extra letter 1 has been added by him because he split it up in three sections.
The functions which start with a single * are the final version.

The lines with two stars (showing below as an empty circle) are the explanation for the additional integer parameter pertaining to that one new function.
Underneath are the three * starred lines (showing as sold square in your software)which are the original functions, from which the new function was created.
I mentioned once before that we were planning to make all functions with results, and therefore the word "procedure" or "function" is not there. Some result is always returned for use by the next function as one parameter (if you wish to).

I am not interested in responding to the comments about my knowledge of C Plus or C Plus Plus or C Plus Plus Plus or C Plus Plus Plus Plus or C Plus.... ad infinatum. It is totally irrelevant.
The class has moved on to another low level language (Harbour) and minigui and also the QT GUI. So further feedback and discussion is not possible.

Please note that the following is only one third of that long list of functions in the original. The integer numbers were somewhat arbitrary, and I had asked for a better co-ordination between different sections.

Functions/Procedures

• rtext_is (Link: #RTEXT_IS)( atom rich)
  • result 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • is_selection_bold (Link: #IS_SELECTION_BOLD)( atom rich )
    • is_selection_italics (Link: #IS_SELECTION_ITALIC)( atom rich )
    • is_selection_underlined (Link: #IS_SELECTION_UNDERLINED)( atom rich )
• rtext_apply (Link: #RTEXT_APPLY)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • apply_bold_to_selection (Link: #APPLY_BOLD_TO_SELECTION)( atom rich )
    • apply_italic_to_selection (Link: #APPLY_ITALIC_TO_SELECTION)( atom rich )
    • apply_underline_to_selection (Link: #APPLY_UNDERLINE_TO_SELECTION)( atom rich )
• rtext_begin (Link: #RTEXT_BEGIN)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • begin_bold (Link: #BEGIN_BOLD)( atom rich )
    • begin_italic (Link: #BEGIN_ITALIC)( atom rich )
    • begin_underline (Link: #BEGIN_UNDERLINE)( atom rich )
• rtext_end (Link: #RTEXT_END)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • end_bold (Link: #END_BOLD)( atom rich )
    • end_italic (Link: #END_ITALIC)( atom rich )
    • end_underline (Link: #END_UNDERLINE)( atom rich )
• rich_undo (Link: #RICH_UNDO)( atom rich, integer action )
  **action: 1=begin suppress, 2=suppressing, 3=end suppress, 12=batch, 13=end batch
  • • begin_suppress_undo (Link: #BEGIN_SUPPRESS_UNDO)( atom rich )
    • suppressing_undo (Link: #SUPPRESSING_UNDO)( atom rich )
    • end_suppress_undo (Link: #END_SUPPRESS_UNDO)( atom rich )
    • batching_undo (Link: #BATCHING_UNDO)( atom rich )
    • end_batch_undo (Link: #END_BATCH_UNDO)( atom rich )
• get_rich_style (Link: #GET_RICH_STYLE)( atom rich, integer which )
  • which: 1= get basic style, 2=get style sheet
    • get_basic_rich_style (Link: #GET_BASIC_RICH_STYLE)( atom rich )
    • get_rich_style_sheet (Link: #GET_RICH_STYLE_SHEET)( atom rich )
• end_rich_styles (Link: #END_RICH_STYLES)( atom rich, integer which )
  • which: 0=all, 1=char, 2=list
    • end_all_rich_styles (Link: #END_ALL_RICH_STYLE)( atom rich )
    • end_char_style (Link: #END_CHAR_STYLE)( atom rich )
    • end_list_style (Link: #END_LIST_STYLE)( atom rich )
• end_spacing (Link: #END_SPACING)( atom rich, integer spacing )
  • spacing: 0=end allignment, 1=left indent, 2=right indent, 3=line spacing, 4=para spacing
    • end_alignment (Link: #END_ALIGNMENT)( atom rich )
    • end_left_indent (Link: #END_LEFT_INDENT)( atom rich )
    • end_right_indent (Link: #END_RIGHT_INDENT)( atom rich )
    • end_line_spacing (Link: #END_LINE_SPACING)( atom rich )
    • end_paragraph_spacing (Link: #END_PARAGRAPH_SPACING)( atom rich )
• end_rfont (Link: #END_RFONT)( atom rich, what )
  • what: 0=font, 1=size, 2=color
    • end_font (Link: #END_FONT)( atom rich )
    • end_font_size (Link: #END_FONT_SIZE)( atom rich )
    • end_text_color (Link: #END_TEXT_COLOR)( atom rich )
• end_bullet (Link: #END_BULLET)( atom rich, integer bullet )
  • which: -1=symbol, 0=standard, 1=>0 = numbered bullet
    • end_symbol_bullet (Link: #END_SYMBOL_BULLET)( atom rich )
    • end_standard_bullet (Link: #END_STANDARD_BULLET)( atom rich )
    • end_numbered_bullet (Link: #END_NUMBERED_BULLET)( atom rich )
• rich_misc (Link: #RICH_MISC)( atom rich, integer misc )
  • misc: 0=def to cursor style, 1=end url, 2=internal selection range, 3=selection range, 4=line break, 5=select none
    • set_default_style_to_cursor_style (Link: #SET_DEFAULT_STYLE_TO_CURSOR_STYLE)( atom rich )
    • end_url (Link: #END_URL)( atom rich )
    • get_rich_internal_selection_range (Link: #GET_RICH_INTERNAL_SELECTION_RANGE)( atom rich )
    • get_rich_selection_range (Link: #GET_RICH_SELECTION_RANGE)( atom rich )
    • line_break (Link: #LINE_BREAK)( atom rich )
    • select_none (Link: #SELECT_NONE)( atom rich )

40. Re: Keywords and Namesapces

• Posted by Vinoba Nov 16, 2011
• 39147 views
• Last edited Nov 17, 2011

I did not know you counted the number of lines as a criteria!

the whole discussion, sir, is about reducing the number of functions.
The original as posted by Matt in the file wxTreeCtrl.txt had 63 functions.
My assignment to the students to reduce the NUMBER OF FUNTIONS and try to stick to 10-12 per file.
The students came with almost all files at 3-12 functions except two which had to be split.
wxTreeCtrl1.txt has 11 functions.
wxTreeCtrl2.txt has 13 functions.
wxTreeCtrl2.txt has 10 functions.
THEREFORE, SIR, the reduction in the number of functions (from 96 to 34) is 66%
There are over 1600 functions and we managed to dwindle them down to about 650, i.e. over 59% reduction.

The original has 96 functions.

Functions/Procedures

• add_paragraph (Link: #ADD_PARAGRAPH)( atom rich, sequence text )
• add_rich_image (Link: #ADD_RICH_IMAGE)( atom rich, atom image )
• apply_alignment_to_selection (Link: #APPLY_ALIGNMENT_TO_SELECTION)( atom rich, atom alignment )
• apply_bold_to_selection (Link: #APPLY_BOLD_TO_SELECTION)( atom rich )
• apply_italic_to_selection (Link: #APPLY_ITALIC_TO_SELECTION)( atom rich )
• apply_rich_style (Link: #APPLY_RICH_STYLE)( atom rich, atom style_def )
• apply_rich_style_sheet (Link: #APPLY_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
• apply_underline_to_selection (Link: #APPLY_UNDERLINE_TO_SELECTION)( atom rich )
• batching_undo (Link: #BATCHING_UNDO)( atom rich )
• begin_alignment (Link: #BEGIN_ALIGNMENT)( atom rich, atom align )
• begin_batch_undo (Link: #BEGIN_BATCH_UNDO)( atom rich, sequence cmd_name )
• begin_bold (Link: #BEGIN_BOLD)( atom rich )
• begin_char_style (Link: #BEGIN_CHAR_STYLE)( atom rich, sequence named_style )
• begin_font (Link: #BEGIN_FONT)( atom rich, atom font )
• begin_font_size (Link: #BEGIN_FONT_SIZE)( atom rich, atom size )
• begin_italic (Link: #BEGIN_ITALIC)( atom rich )
• begin_left_indent (Link: #BEGIN_LEFT_INDENT)( atom rich, atom indent, atom sub_indent )
• begin_line_spacing (Link: #BEGIN_LINE_SPACING)( atom rich, atom spacing )
• begin_list_style (Link: #BEGIN_LIST_STYLE)( atom rich, sequence named_style, atom level, atom number )
• begin_numbered_bullet (Link: #BEGIN_NUMBERED_BULLET)( atom rich, atom number, atom indent, atom sub_indent, atom style )
• begin_paragraph_spacing (Link: #BEGIN_PARAGRAPH_SPACING)( atom rich, atom before, atom after )
• begin_paragraph_style (Link: #BEGIN_PARAGRAPH_STYLE)( atom rich, sequence named_style )
• begin_rich_style (Link: #BEGIN_RICH_STYLE)( atom rich, atom style )
• begin_right_indent (Link: #BEGIN_RIGHT_INDENT)( atom rich, atom indent )
• begin_standard_bullet (Link: #BEGIN_STANDARD_BULLET)( atom rich, sequence bullet_name, atom indent, atom sub_indent, atom style )
• begin_suppress_undo (Link: #BEGIN_SUPPRESS_UNDO)( atom rich )
• begin_symbol_bullet (Link: #BEGIN_SYMBOL_BULLET)( atom rich, sequence symbol, atom indent, atom sub_indent, atom style )
• begin_text_color (Link: #BEGIN_TEXT_COLOR)( atom rich, atom color )
• begin_underline (Link: #BEGIN_UNDERLINE)( atom rich )
• begin_url (Link: #BEGIN_URL)( atom rich, sequence url, sequence style )
• end_alignment (Link: #END_ALIGNMENT)( atom rich )
• end_all_rich_styles (Link: #END_ALL_RICH_STYLE)( atom rich )
• end_batch_undo (Link: #END_BATCH_UNDO)( atom rich )
• end_bold (Link: #END_BOLD)( atom rich )
• end_char_style (Link: #END_CHAR_STYLE)( atom rich )
• end_font (Link: #END_FONT)( atom rich )
• end_font_size (Link: #END_FONT_SIZE)( atom rich )
• end_italic (Link: #END_ITALIC)( atom rich )
• end_left_indent (Link: #END_LEFT_INDENT)( atom rich )
• end_line_spacing (Link: #END_LINE_SPACING)( atom rich )
• end_list_style (Link: #END_LIST_STYLE)( atom rich )
• end_numbered_bullet (Link: #END_NUMBERED_BULLET)( atom rich )
• end_paragraph_spacing (Link: #END_PARAGRAPH_SPACING)( atom rich )
• end_paragraph_style (Link: #END_PARAGRAPH_STYLE)( atom rich )
• end_rich_style (Link: #END_RICH_STYLE)( atom rich )
• end_right_indent (Link: #END_RIGHT_INDENT)( atom rich )
• end_standard_bullet (Link: #END_STANDARD_BULLET)( atom rich )
• end_suppress_undo (Link: #END_SUPPRESS_UNDO)( atom rich )
• end_symbol_bullet (Link: #END_SYMBOL_BULLET)( atom rich )
• end_text_color (Link: #END_TEXT_COLOR)( atom rich )
• end_underline (Link: #END_UNDERLINE)( atom rich )
• end_url (Link: #END_URL)( atom rich )
• get_basic_rich_style (Link: #GET_BASIC_RICH_STYLE)( atom rich )
• get_rich_internal_selection_range (Link: #GET_RICH_INTERNAL_SELECTION_RANGE)( atom rich )
• get_rich_selection_range (Link: #GET_RICH_SELECTION_RANGE)( atom rich )
• get_rich_style_sheet (Link: #GET_RICH_STYLE_SHEET)( atom rich )
• has_char_rich_attr (Link: #HAS_CHAR_RICH_ATTR)( atom rich, atom first, atom last, atom rich_attr )
• has_char_text_attr (Link: #HAS_CHAR_TEXT_ATTR)( atom rich, atom first, atom last, atom text_attr_ex )
• has_para_char_attr (Link: #HAS_PARA_CHAR_ATTR)( atom rich, atom first, atom last, atom rich_attr )
• has_para_text_attr (Link: #HAS_PARA_TEXT_ATTR)( atom rich, atom first, atom last, atom text_attr_ex )
• is_selection_aligned (Link: #IS_SELECTION_ALIGNED)( atom rich, atom alignment )
• is_selection_bold (Link: #IS_SELECTION_BOLD)( atom rich )
• is_selection_italics (Link: #IS_SELECTION_ITALIC)( atom rich )
• is_selection_underlined (Link: #IS_SELECTION_UNDERLINED)( atom rich )
• layout_rich_content (Link: #LAYOUT_RICH_CONTENT)( atom rich, atom only_visible )
• line_break (Link: #LINE_BREAK)( atom rich )
• move_down (Link: #MOVE_DOWN)( atom rich, atom n_pos, atom flags )
• move_end (Link: #MOVE_END)( atom rich, atom flags )
• move_home (Link: #MOVE_HOME)( atom rich, atom flags )
• move_left (Link: #MOVE_LEFT)( atom rich, atom n_pos, atom flags )
• move_rich_caret (Link: #MOVE_RICH_CARET)( atom rich, atom pos, atom at_start )
• move_right (Link: #MOVE_RIGHT)( atom rich, atom n_pos, atom flags )
• move_to_line_end (Link: #MOVE_TO_LINE_END)( atom rich, atom flags )
• move_to_line_start (Link: #MOVE_TO_LINE_START)( atom rich, atom flags )
• move_to_paragraph_end (Link: #MOVE_TO_PARAGRAPH_END)( atom rich, atom flags )
• move_to_paragraph_start (Link: #MOVE_TO_PARAGRAPH_START)( atom rich, atom flags )
• move_up (Link: #MOVE_UP)( atom rich, atom n_pos, atom flags )
• page_down (Link: #PAGE_DOWN)( atom rich, atom pages, atom flags )
• page_up (Link: #PAGE_UP)( atom rich, atom pages, atom flags )
• pop_rich_style_sheet (Link: #POP_RICH_STYLE_SHEET)( atom rich )
• push_rich_style_sheet (Link: #PUSH_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
• select_none (Link: #SELECT_NONE)( atom rich )
• select_word (Link: #SELECT_WORD)( atom rich, atom pos )
• set_basic_rich_style (Link: #SET_BASIC_RICH_STYLE)( atom rich, atom style )
• set_basic_rich_text_style (Link: #SET_BASIC_RICH_TEXT_STYLE)( atom rich, atom style )
• set_default_style_to_cursor_style (Link: #SET_DEFAULT_STYLE_TO_CURSOR_STYLE)( atom rich )
• set_rich_internal_selection_range (Link: #SET_RICH_INTERNAL_SELECTION_RANGE)( atom rich, atom start, atom finish )

• set_rich_selection_range (Link: #SET_RICH_SELECTION_RANGE)( atom rich, atom start, atom finish )
• set_rich_style_sheet (Link: #SET_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
• suppressing_undo (Link: #SUPPRESSING_UNDO)( atom rich )
• word_left (Link: #WORD_LEFT)( atom rich, atom words, atom flags )
• word_right (Link: #WORD_RIGHT)( atom rich, atom words, atom flags )
• write_image (Link: #WRITE_IMAGE)( atom rich, atom image, atom bitmap_type )
• write_image_block (Link: #WRITE_IMAGE_BLOCK)( atom rich, atom image_block )
• write_image_from_file (Link: #WRITE_IMAGE_FROM_FILE)( atom rich, sequence filename, atom bitmap_type )

After reducing the number of functions three files were created and had, 11,13,and 10 functions.

Functions/Procedures (11 functions in section 1)

• rtext_is (Link: #RTEXT_IS)( atom rich)
  • result 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • is_selection_bold (Link: #IS_SELECTION_BOLD)( atom rich )
    • is_selection_italics (Link: #IS_SELECTION_ITALIC)( atom rich )
    • is_selection_underlined (Link: #IS_SELECTION_UNDERLINED)( atom rich )
• rtext_apply (Link: #RTEXT_APPLY)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • apply_bold_to_selection (Link: #APPLY_BOLD_TO_SELECTION)( atom rich )
    • apply_italic_to_selection (Link: #APPLY_ITALIC_TO_SELECTION)( atom rich )
    • apply_underline_to_selection (Link: #APPLY_UNDERLINE_TO_SELECTION)( atom rich )
• rtext_begin (Link: #RTEXT_BEGIN)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • begin_bold (Link: #BEGIN_BOLD)( atom rich )
    • begin_italic (Link: #BEGIN_ITALIC)( atom rich )
    • begin_underline (Link: #BEGIN_UNDERLINE)( atom rich )
• rtext_end (Link: #RTEXT_END)( atom rich, integer rfont)
  • rfont: 1=bold, 2=italic, 3= bold+italic, 4=underlined, 5=bold+underlined, 6= italic+underlined, 7= all three
    • end_bold (Link: #END_BOLD)( atom rich )
    • end_italic (Link: #END_ITALIC)( atom rich )
    • end_underline (Link: #END_UNDERLINE)( atom rich )
• rich_undo (Link: #RICH_UNDO)( atom rich, integer action ) **action: 1=begin suppress, 2=suppressing, 3=end suppress, 12=batch, 13=end batch
  • • begin_suppress_undo (Link: #BEGIN_SUPPRESS_UNDO)( atom rich )
    • suppressing_undo (Link: #SUPPRESSING_UNDO)( atom rich )
    • end_suppress_undo (Link: #END_SUPPRESS_UNDO)( atom rich )
    • batching_undo (Link: #BATCHING_UNDO)( atom rich )
    • end_batch_undo (Link: #END_BATCH_UNDO)( atom rich )
• get_rich_style (Link: #GET_RICH_STYLE)( atom rich, integer which )
  • which: 1= get basic style, 2=get style sheet
    • get_basic_rich_style (Link: #GET_BASIC_RICH_STYLE)( atom rich )
    • get_rich_style_sheet (Link: #GET_RICH_STYLE_SHEET)( atom rich )
• end_rich_styles (Link: #END_RICH_STYLES)( atom rich, integer which )
  • which: 0=all, 1=char, 2=list
    • end_all_rich_styles (Link: #END_ALL_RICH_STYLE)( atom rich )
    • end_char_style (Link: #END_CHAR_STYLE)( atom rich )
    • end_list_style (Link: #END_LIST_STYLE)( atom rich )
• end_spacing (Link: #END_SPACING)( atom rich, integer spacing )
  • spacing: 0=end allignment, 1=left indent, 2=right indent, 3=line spacing, 4=para spacing
    • end_alignment (Link: #END_ALIGNMENT)( atom rich )
    • end_left_indent (Link: #END_LEFT_INDENT)( atom rich )
    • end_right_indent (Link: #END_RIGHT_INDENT)( atom rich )
    • end_line_spacing (Link: #END_LINE_SPACING)( atom rich )
    • end_paragraph_spacing (Link: #END_PARAGRAPH_SPACING)( atom rich )
• end_rfont (Link: #END_RFONT)( atom rich, what )
  • what: 0=font, 1=size, 2=color
    • end_font (Link: #END_FONT)( atom rich )
    • end_font_size (Link: #END_FONT_SIZE)( atom rich )
    • end_text_color (Link: #END_TEXT_COLOR)( atom rich )
• end_bullet (Link: #END_BULLET)( atom rich, integer bullet )
  • which: -1=symbol, 0=standar, 1=>0 = numbered bullet
    • end_symbol_bullet (Link: #END_SYMBOL_BULLET)( atom rich )
    • end_standard_bullet (Link: #END_STANDARD_BULLET)( atom rich )
    • end_numbered_bullet (Link: #END_NUMBERED_BULLET)( atom rich )
• rich_misc (Link: #RICH_MISC)( atom rich, integer misc )
  • misc: 0=def to cursor style, 1=end url, 2=internal selection range, 3=selection range, 4=line break, 5=slect none
    • set_default_style_to_cursor_style (Link: #SET_DEFAULT_STYLE_TO_CURSOR_STYLE)( atom rich )
    • end_url (Link: #END_URL)( atom rich )
    • get_rich_internal_selection_range (Link: #GET_RICH_INTERNAL_SELECTION_RANGE)( atom rich )
    • get_rich_selection_range (Link: #GET_RICH_SELECTION_RANGE)( atom rich )
    • line_break (Link: #LINE_BREAK)( atom rich )
    • select_none (Link: #SELECT_NONE)( atom rich )

Functions/Procedures (13 functions in Section 2)

• has_rich_attr (Link: #HAS_RICH_ATTR)( atom rich, atom first, atom last, atom rich_attr, integer which )
  • which: 1=char_rich, 2=text_rich, 3=para char, 4=text char
    • has_char_rich_attr (Link: #HAS_CHAR_RICH_ATTR)( atom rich, atom first, atom last, atom rich_attr )
    • has_char_text_attr (Link: #HAS_CHAR_TEXT_ATTR)( atom rich, atom first, atom last, atom text_attr_ex )
    • has_para_char_attr (Link: #HAS_PARA_CHAR_ATTR)( atom rich, atom first, atom last, atom rich_attr )
    • has_para_text_attr (Link: #HAS_PARA_TEXT_ATTR)( atom rich, atom first, atom last, atom text_attr_ex )
• selection_alignment (Link: #SELECTION_ALIGNMENT)( atom rich, atom alignment, integer action )
  • action: -1 = is aligned?, 0=begin, 1=apply
    • is_selection_aligned (Link: #IS_SELECTION_ALIGNED)( atom rich, atom alignment)
    • begin_alignment (Link: #BEGIN_ALIGNMENT)( atom rich, atom align )
    • apply_alignment_to_selection (Link: #APPLY_ALIGNMENT_TO_SELECTION)( atom rich, atom alignment )
• begin_left_indent (Link: #BEGIN_LEFT_INDENT)( atom rich, atom indent, atom sub_indent )
• rich_begins_more(Link: #RICH_BEGINS_MORE)( atom rich, atom value, integer action )
  • action: 1=font size, 2=right indent, 3=line spacing
    • begin_font_size (Link: #BEGIN_FONT_SIZE)( atom rich, atom size )
    • begin_right_indent (Link: #BEGIN_RIGHT_INDENT)( atom rich, atom indent )
    • begin_line_spacing (Link: #BEGIN_LINE_SPACING)( atom rich, atom spacing )
• select_word (Link: #SELECT_WORD)( atom rich, atom pos )
• rich_style_sheet (Link: #RICH_STYLE_SHEET)( atom rich, atom style_sheet, integer action )
  • action: -1=push, 0=set, 1=apply
    • push_rich_style_sheet (Link: #PUSH_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
    • set_rich_style_sheet (Link: #SET_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
    • apply_rich_style_sheet (Link: #APPLY_RICH_STYLE_SHEET)( atom rich, atom style_sheet )
• rich_style (Link: #RICH_STYLE)( atom rich, atom style, integer action )
  • action: 0=begin, 1=set basic style, 2=set basic text style
    • begin_rich_style (Link: #BEGIN_RICH_STYLE)( atom rich, atom style )
    • set_basic_rich_style (Link: #SET_BASIC_RICH_STYLE)( atom rich, atom style )
    • set_basic_rich_text_style (Link: #SET_BASIC_RICH_TEXT_STYLE)( atom rich, atom style )
• set_selection_range (Link: #SET_SELECTION_RANGE)( atom rich, atom start, atom finish, integer action )
  • action: -1=internal range, 0= paragraph spacing, 1=range
    • set_rich_internal_selection_range (Link: #SET_RICH_INTERNAL_SELECTION_RANGE)( atom rich, atom start, atom finish )
    • begin_paragraph_spacing (Link: #BEGIN_PARAGRAPH_SPACING)( atom rich, atom before, atom after )
    • set_rich_selection_range (Link: #SET_RICH_SELECTION_RANGE)( atom rich, atom start, atom finish )
• move_extreme (Link: #MOVE_EXTREME)( atom rich, atom flags, integer dest )
  • dest: -3=to para start, -2=line start, -1=home, 1=end, 2=line end, 3=para end
    • move_to_paragraph_start (Link: #MOVE_TO_PARAGRAPH_START)( atom rich, atom flags )
    • move_to_line_start (Link: #MOVE_TO_LINE_START)( atom rich, atom flags )
    • move_home (Link: #MOVE_HOME)( atom rich, atom flags )
    • move_end (Link: #MOVE_END)( atom rich, atom flags )
    • move_to_line_end (Link: #MOVE_TO_LINE_END)( atom rich, atom flags )
    • move_to_paragraph_end (Link: #MOVE_TO_PARAGRAPH_END)( atom rich, atom flags )
• move_rcaret (Link: #MOVE_RCARET)( atom rich, atom n_pos, atom flags, integer deviation )
  • deviation: -2=left, -1=up, 0=move caret, 1=down, 2=right
    • move_left (Link: #MOVE_LEFT)( atom rich, atom n_pos, atom flags )
    • move_up (Link: #MOVE_UP)( atom rich, atom n_pos, atom flags )
    • move_rich_caret (Link: #MOVE_RICH_CARET)( atom rich, atom pos, atom at_start )
    • move_down (Link: #MOVE_DOWN)( atom rich, atom n_pos, atom flags )
    • move_right (Link: #MOVE_RIGHT)( atom rich, atom n_pos, atom flags )
• move_wordspages (Link: #MOVE_WORDSPAGES)( atom rich, atom pages, atom flags, integer howmuch )
  • howmuch: -2=word left, -1=up, 1=down, 2=right
    • word_left (Link: #WORD_LEFT)( atom rich, atom words, atom flags )
    • page_up (Link: #PAGE_UP)( atom rich, atom pages, atom flags )
    • page_down (Link: #PAGE_DOWN)( atom rich, atom pages, atom flags )
    • word_right (Link: #WORD_RIGHT)( atom rich, atom words, atom flags )
• paragraph_text (Link: #PARAGRAPH_TEXT)( atom rich, sequence text, integer action)
  • action: 0=begin, 1=add
    • begin_paragraph_style (Link: #BEGIN_PARAGRAPH_STYLE)( atom rich, sequence named_style )
    • add_paragraph (Link: #ADD_PARAGRAPH)( atom rich, sequence text )
• rich_bullets (Link: #RICH_BULLETS)( atom rich, sequence anything, atom indent, atom sub_indent, atom style, integer action )
  • action: 1=numbered, 2= standard, 3=symbol.. anyhting: sequence number,or bullet name or sympbol.
    • begin_numbered_bullet (Link: #BEGIN_NUMBERED_BULLET)( atom rich, atom number, atom indent, atom sub_indent, atom style )
    • begin_standard_bullet (Link: #BEGIN_STANDARD_BULLET)( atom rich, sequence bullet_name, atom indent, atom sub_indent, atom style )
    • begin_symbol_bullet (Link: #BEGIN_SYMBOL_BULLET)( atom rich, sequence symbol, atom indent, atom sub_indent, atom style )

Functions/Procedures (10 functions in section 3)

• apply_rich_style (Link: #APPLY_RICH_STYLE)( atom rich, atom style_def )
• begin_font (Link: #BEGIN_FONT)( atom rich, atom font )
• begin_list_style (Link: #BEGIN_LIST_STYLE)( atom rich, sequence named_style, atom level, atom number )
• begin_text_color (Link: #BEGIN_TEXT_COLOR)( atom rich, atom color )
• begin_url (Link: #BEGIN_URL)( atom rich, sequence url, sequence style )
• layout_rich_content (Link: #LAYOUT_RICH_CONTENT)( atom rich, atom only_visible )
• add_rich_image (Link: #ADD_RICH_IMAGE)( atom rich, atom image )
• write_image (Link: #WRITE_IMAGE)( atom rich, atom image, atom bitmap_type )
• write_image_block (Link: #WRITE_IMAGE_BLOCK)( atom rich, atom image_block )
• write_image_from_file (Link: #WRITE_IMAGE_FROM_FILE)( atom rich, sequence filename, atom bitmap_type )

I suggest you try and be professional when you look at it. This is not one of those forums where people try to ridicule others.
I will restate: An over 66% reduction in the number of functions and full details shown above. The total for all the 169 files was an over 59% reduction.

42. Re: Keywords and Namesapces

• Posted by Vinoba Nov 17, 2011
• 39123 views

I had posted by mistake the Tree control original file instead of the Richtext control original file. I have edited it. It was by mistake apples and oranges before; now it is clearly all apples with unwanted ones taken out and new fewer apples put in

The work I intended to show was for the original Richtext control functions (currently 96, not 63 as I originally stated) which are now reduced to 34. Because of my directive to keep the number of functions in a file to 10-12, the students had split it to three files - one file with 11 functions, a second file with 13 functions and a third file with the remaining 10 functions. The first two files show the old (discontinued) functions with a square marker and the new functions with a bold circular marker. the third file has the remaining unaltered functions- functions they could not reduce in number mainly because of the number and types of parameters.

As I said before the total of over 1600 functions in wxEuphoria has been reduced to about 650, without sacrificing any functionality. It is NOT my intention to write to wxWidgets, because this exercise is over. I have given extensive demo above (edited 10 minutes ago) for anybody to see what can be done, and how it can be done. It is not a question of whether it can be done, but whether the approach taken by me is suitable overall for the common good of all Euphoria users using wxEuporia. If Matt decides to go that route (he has already rejected the idea), he will have to fine tune the details.

44. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Nov 17, 2011
• 39105 views

Agreed. It is not necessary to continously point this out, as everyone who has ever posted on this thread to date agrees with this point.

Any particular reason why other, non-Euphorian users of wxWidgets should be excluded from these benefits?

Detail which you indicated had already been fleshed out into functional code. An "extensive demo" that consists of nothing but statistics and documentation.

You are asking Matt (or anyone else who may want to follow up on and expand this idea) to redo the entire thing from scratch. Might as well ask him to re-invent the wheel.

46. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Nov 17, 2011
• 39070 views

Agreed. To this extend, wxEuphoria is a very thin wrapper.

Since wxEuphoria is a very thin wrapper, it should be identical to wxWidgets in the manner of the approach (or more explicitly, the use of name choice, the style of names, the style of classes, etc.).

Although you have not said that you explicitly doubt the validity of the approach of wxEuphoria, the fact that you believe these changes to be useful only to wxEuphoria and not to wxWidgets implies it.

So, why do you doubt the validity of the approach for wxEuphoria, when you feel that the same one works for wxWidgets?

What does that mean?

Either the approach of wxWidgets is itself against the philosophy of Euphoria (I don't believe this is true) and therefore the simple "thin wrapper" style is inappropriate for Euphoria programming (I don't buy this at all), or the language behind wxWidgets is so different to the point that the concepts used by wxWidgets can't be expressed in Euphoria (but the existence of the current form of wxEuphoria shows that this is clearly false).

The approach of wxWidgets is almost perfectly expressed by wxEuphoria (with a small caveat that Matt had previously mentioned here), and your demonstration suggests a significant change to it.

Useful? Easier? Better? For the sake of argument I'll accept all these. Just keep in mind that your recommendation, rather than being an attempt to better express the C format of wxWidgets in Euphoria, is actually a move away from the current form of wxWidgets to make wxEuphoria less similiar to it.

Of course, these changes can be directly applied to wxWidgets itself, or a fork of it. There is nothing in them that suggests that an interested party would be unable to do this.

You also state that you want to make programming easier. Yet, as Matt pointed out, all of the benefits you stated seemed to depend on a special IDE that is not publicly available. Even though I'd expressed skeptcism in the past that even this IDE would benefit, let us again assume for the sake of argument that this is true.

How's it make programming easier for the rest of us?

Why only Matt? It's possible that someone else might come along and like your approach and make a new fork of wxEuphoria based on it.

Except that they can't. They'd have to start from scratch (well, from the current version of wxEuphoria) and do all the legwork from there.

Let's assume Matt did make the decision to use this. He'd also have to do all the heavy lifting himself.

You bring a new idea, and claim that the code to prove that it works has already been written, but essentially require that anyone else who agrees and wants to give it a try has to reinvent the wheel. You may not be literally asking anyone to do that, but it seems that the wheel has to be reinvented, regardless.

48. Re: Keywords and Namesapces

• Posted by jimcbrown (admin) Nov 17, 2011
• 39103 views

If you look closely at the docs, the integer parameter being suggested works differently. It is not used to distinguish the target class.

Instead it tends to have a meaning akin to:

enum stuff { BOLD, ITALIC, BOLD_PLUS_ITALIC, UNDERLINE... } 

Totally different.

50. Re: Keywords and Namesapces

• Posted by Vinoba Nov 17, 2011
• 39014 views

I will comment at length tonight, when I have time. In the meantime, i suggest, please get away from the concept of "class" etc.
I job has to be done, and a pyramid of functions is to be built on top of the basic CPU function of move one value from one register to another or do some simple arithmetic with one value in a register to a value pointed to be another register, etc., etc., etc,etc.
The libraries (including wxWidgets build a part of a pyramid on top of these basic functions of CPU functions.

With euphoria you add to this pyramid and so on to the final application on the desktop of some Banking genius who can make billions disappear from the economy.
In that process, one has to consolidate, remove functions, etc. e.g.
Whether you give access via 5 separate functions to change to bold, italic, underline etc, or give one function to say, something like this hypothetical function:-

change-font(agridid,scell,sfontname,iweight,bitalic,bunderline,icolournumber) 
-- a prefix used for atom, s for sequence, i for integer and b for boolean 

This decision has NOTHING to do with developers of wxWidgets, and is entirely in the province of the developers of higher language who would like to use the facility of wxWidgets in THEIR OWN UNIQUE WAY and create their own UNIQUE APPROACH to using these facilites. Every new layer causes loss of speed of final execution (in the Interpreter), which is mostly nullified by creating an executable.

All the change made to reduce the number of functions, were executed using small Euphoria functions and
if ... then

52. Re: Keywords and Namesapces

• Posted by Vinoba Nov 17, 2011
• 38992 views
• Last edited Nov 18, 2011

Matt says: “The difficulty is in mapping object oriented C plus plus code to procedural C and Euphoria.”
I say: Please continue doing what you are doing there. I am not suggesting any change there.
Matt says: “My understanding of Vinoba's proposal is to add an integer parameter to distinguish the target class.”
My proposal is to add an integer parameter to simply combine 2-8 functions as one function. In its simplest form, you have in the file “wxFlexGridSizer”, the following two functions:- (Notice I use the word “file” not “Class”)

add_growable_col ( atom sizer, atom idx, atom proportion )  
-- (Link: #ADD_GROWABLE_COL)   
add_growable_row ( atom sizer, atom idx, atom proportion ) 
-- (Link: #ADD_GROWABLE_ROW)  

I/we noticed that both the functions have the same three parameters, viz.
atom sizer
atom idx
atom proportion

So we create a new function with the same parameters and add one more parameter “integer colrow” and remove the words “row” and “col” from the two names.

add_growable (Link: #ADD_GROWABLE)( atom sizer, atom idx, atom proportion, integer colrow ) 
-- colrow: 1=col, 2=row    
-- Here I have arbitrarily defined variable “colrow” to mean col if its value is 1  
-- and row if its value is 2.  
-- If the methodology is adopted, we must try and use the same values for rows and columns throughout. 

Then we define in a new wxeudex.e, where all these changes will be accommodated.

include wxeud.e 
-- 
public constant newpara_error = 9999 
-- 
public function add_growable ()( atom sizer, atom idx, atom proportion, integer colrow ) 
    if (colrow < 1) or (colrow > 2) then 
       return newpara_error  
--  We retun an error.  Error No 9999 has been defined as a universal error number for the new work. 
-- 
    end if 
 
    if colrow = 1 then 
       add_growable_col (  sizer, idx,  proportion )    
    end if 
 
    if colrow=2 then 
       add_growable_row (  sizer, idx,  proportion )    
    end if 
    return colrow  
-- since these were originally "procedures" in wxeud.e, and we want to use them as functions,  
-- we return something. 
-- we could return the atom sizer, or anything else if that is likely to be more useful  
-- for becoming an argument (parameter) to the next function. 
 
end function   

No major change to the existing work.
In fact, the existing functions "add_growable_col" and "add_growable_row" remain usable till finally deprecated.

54. Re: Keywords and Namesapces

• Posted by ne1uno Nov 18, 2011
• 38998 views

Qt has a meta compiler, so it is relatively easy in euqt to determine the type of most widgets and call the correct set/get_text() including for the clipboard. at a little loss of efficiency & safety, because in a wrapper this happens at runtime, but it must be hardly noticeable unless you include the time it takes to fit everything into one function. and most widgets in Qt inherent from the the same class so are the same size. which makes it less prone to crash.

depending on always using the correct enum with the intended widget in a consolidated function is asking too much. you may not find the mistake unless you have full coverage and not even then.

different widgets accept various parameters and you also have to have some default values and manage them. set_text on a tree vrs a tooltip, you are loosing a little there by passing default NULL for things the tree requires but the tooltip doesn't.

you have to have the API docs open no matter, may as well try to keep the end user code easy to read. so you compromise and have set_text(tree, "") only work on the current selected node. the end user has no idea of that compromise. so now you need two docs open. set & get text would seem to be simple. all the exceptions have to be maintained as the original GUI changes too.

wrapping the wrap is an easier way to test the theory that less functions is more functional. build on the already working/tested/used wrap. "you" may find the cost of converting existing demos and sample code & docs now in the native GUI takes more work.

not exactly the same topic, hall-of-api-shame-boolean-trap