Lisp symbol naming convention

[owenwengerd]

I've always been irritated by the project_form_control naming convention, and I'm thinking about what it would take to change the convention in OpenDCL 8. My main concern is the underscore symbol. I'd prefer something like project/form/control. For functions and methods, I'd prefer the hyphen as a delimiter to follow the visual lisp convention, so (dcl_Form_Show) becomes (dcl-Form-Show).

This is partly an aesthetic issue, but also partly a practical/functional issue. Naming controls like project/form/control makes it more intuitive to visualize the hierarchy, and makes it easier to work with nested forms (or tab pages) addressed like Project/Form/Childform/Tabpage/Control. The current naming convention becomes unwieldy when you start referring to nested controls with a "complete" path. For events handlers, controls or forms with an underscore character in their name result in confusing names using the current convention.

The question is, how painful will it be to transition. For events, it's no problem at all: old projects will continue to use the old name since the handler name is embedded in the project. For functions and methods I just have to create new function names, but leave the old names defined as well so that old code continues to work. It seems a bit messy, but for lisp symbol names I can also set both the old style and the new style names simultaneously so that old code will continue to work.

Am I missing anything? What do you guys think?

[garcigj]

I've been looking at a project any examples and I liked the nomenclature especially in the event, it is easy to quickly identify the code by the symbol "#", in terms of functions and methods could create a small program to lisp files open and replace text.

as to the 8.0.0.1 version, I've tried to "MasterDemo" in ac2014 and presents some problems, but this is another matter and we will already talking.

Sorry for my bad English.

[owenwengerd]

That's a good idea to make a small lisp utility to update lisp files. You have to be careful, because if controls include an underscore in their name, the conversion should be project_form_con_trol -> project/form/con_trol, which would require knowledge about the control name. I suppose the utility could open the .odcl and programmatically determine the correct control names. In that case it could even update event names, then save the modified .odcl and .lsp files.

[Fred Tomke]

Hi guys, I'm not really sure, if I should be glad about it. I'm even wondering about a special char like '/' is allowed in symbolnames. But it actually is. For my own taste, a '_'-char is more wide and it devides project, form and control much better and it matches much better to other object variables which use '_', too.
And I was not worry about '_' in function names - my .NET based Lisp-function names are also using '_' to seperate app-prefix, upper topic, sub topic and function from each other (like stadtcad_menu_ribbons_regen). But nevertheless, if any issues will be closed with that change, it should be done.

I'm thinking about a replacer for "'dcl_" and "(dcl_" (Search result of my old project "(dcl_" (11663 hits in 56 files)).

Regards, Fred

[Fred Tomke]

Hm, how about defining a custom seperator char for an odcl project for control naming in OpenDCL Studio?
Regards, Fred

[owenwengerd]

Thanks for your input, Fred.

[owenwengerd]

If anyone wants to experiment, I've attached a quick-n-dirty utility to update the symbol and function names in existing odcl projects. I've only done very limited testing with the _MasterDemo sample project. It's not bulletproof. For example, it expects default event handler names in the project, so it will fail to update event handler names if they are no longer default. Load and run UDCL8UPDATE, then select the .odcl files. It will look for and update a .lsp file of the same name, and it will make backups of both files.

[owenwengerd]

After working with the update utility today and spending some time with the new naming convention, I'm pretty satisfied with most things about it. I'm not thrilled with the forward slash "path" separator, but I think it's better than the underscore, and I can't find anything better on a standard US keyboard. I guess adding an option for a user-selected separator would be one solution, but I know from all the places I had to modify the code to make this change that it's not simple to provide that flexibility.

[garcigj]

Owen,
The have a little time, I will test the utility with some of my major projects to see what happens and that may have errors.
... and I do get results

[BazzaCAD]

Sorry I'm late to the game on this one Owen.
Are you saying existing projects (lsp & odcl) would have to be converted or will OpenDCL be backwards comparable?
Can I leave existing projects as-is & just use the new naming convention for new project?

Barry

[owenwengerd]

Old projects should continue to work without modification.

[Emiliano]

If anyone wants to experiment, I've attached a quick-n-dirty utility to update the symbol and function names in existing odcl projects. I've only done very limited testing with the _MasterDemo sample project. It's not bulletproof. For example, it expects default event handler names in the project, so it will fail to update event handler names if they are no longer default. Load and run UDCL8UPDATE, then select the .odcl files. It will look for and update a .lsp file of the same name, and it will make backups of both files.

This utility will convert the project. Odcl with the new nomenclature?
In addition to the project. Odcl also need to convert individual files lisp related to it?
I understand it?

The discussion goes back to January, there are updates?
I have a very complex project and I'm not sure that it is convenient to update to the new nomenclature.
Maybe I can leave things as they are, but that I will have problems in the future with the maintenance of my project?
What should I do?

[owenwengerd]

Yes, the utility updates the .odcl file and the matching lisp file.

If your old project converts cleanly, then I think it would be best to use the utility and convert it. If it does not convert cleanly, then it would be best to leave it as it is. At this point there has been no change since January. As you can see, only a few people have provided feedback. Without feedback, I will continue with the current implementation.

[Emiliano]

I state that I have not converted my project. Maybe I will in the coming days ...

However, I tried to enable an event to a control 'Combo Box' and then copied the code suggested in my lisp file:

Code (autolisp) Select Expand


(defun c:NomeApp_Form/FormMain/ColLayer#OnSelChanged (ItemIndexOrCount Value /)
  (dcl_MessageBox "To Do: code must be added to event handler\r\nc:NomeApp_Form/FormMain/ColLayer#OnSelChanged" "To do")
)


but when i load the lisp file in AutoCAD displays the following error:

Command: (LOAD "C:/Documents and Settings/Anonimo/Desktop/TEST.lsp") ; errore: ads_defun
failed: <nome num cr>:

if I remove the "/" from the name of the function, then the lisp file is loaded correctly.

[owenwengerd]

I don't understand. The error indicates that you added a \ character to the function name. Are you mistyping \ instead of /? In any case, I recommend to copy/paste from Studio instead of typing.