Broken Macros? X11? Dunno...

[HumbleChief]

I don't use macros much and a very few but I went to use them and now get evaluation errors with no changes from this end. Looks like something has changed from invalid names to again eval errors. Is there a new format required? Do I need to recreate?

 

Here's simplest area_Rounded  again forced to rename so maybe that's a clue?

[Joe_Carrick]

Larry,

Do you have an appropriate object selected?  ie: an object that has an "area" attribute.

[Kbird1]

10 minutes ago, HumbleChief said:

I don't use macros much and a very few but I went to use them and now get evaluation errors with no changes from this end. Looks like something has changed from invalid names to again eval errors. Is there a new format required? Do I need to recreate?

 

Here's simplest area_Rounded  again forced to rename so maybe that's a clue?

 

I don't think Chief likes (elevated?) Macro's with Capital Letters anymore, so it changes the 1st letter to lowercase.

[HumbleChief]

Wow they are all now broken and no longer valid in some way. Pretty sure why I don't use macros much....

[HumbleChief]

Weird, they show as invalid but seem to work as a label in a P line box... as they we designed to do?

 

Moving on quickly as macros are of very little help to my small mind...

[Kbird1]

1 hour ago, HumbleChief said:

Wow they are all now broken and no longer valid in some way. Pretty sure why I don't use macros much....

 

Let Chief rename them and all should be well I think.... I am no Macro Master either , but in X10 and more so in X11 you can now use Macros inside macros and the Capital letter breaks them , so it tries to "fix" them for you .....

 

Eric,Joe, BrownTiger or Michael would have to elaborate further on that....

[BrownTiger]

Ruby naming conventions require that Method names should begin with a lowercase letter (or an underscore).

Uppercase reserved for constants. [ Upper case can be used in class defs]

 

http://rubylearning.com/satishtalim/ruby_names.html

 

Since X10, CA started to suggest renaming. So please name your methods: feetToIn and never FeetToIn, constants PI=3.14 and never pi=3.14, 

 

[owner.]area does not work with rooms as rooms have different attributes internal_area, and standard_area. Draw rectangular polyline, selected that polyline, and then open TMM and select your area_rounded macro. 

 

You can always select any object, than open ruby console and type: owner.names, to see the list of available attributes.

 

Nothing is wrong.

[Joe_Carrick]

Renaming isn't really mandatory.  If you do allow Chief to rename them then everyplace you have used the Uppercase version will no longer work because that macro will no longer exist.

 

When Chief asks (suggests) that they be renamed - I just select "Ignore".  It's only in cases where you want to call a macro from within another (as a "method") that it needs to start with a lower case character.  For me, that's almost never.

 

BTW, I think when CA initiated this "Renaming" it was a big mistake.  It's a real PITA to deal with.  Ruby is case sensitive and conventionally uppercase is supposed to be reserved for "Constants" it isn't mandatory to make everything else lowercase..

[Alaskan_Son]

Just as a reminder here, the reason Chief changed the naming rules is that user defined macros can be used as methods now.  I personally think it makes good sense and I just adjusted my naming conventions to suit.

[BrownTiger]

>I just adjusted my naming conventions to suit.

 

+1. BTW Java language also includes the same requirement. While technically you do not have to, I ended up fixing a lot of code for someone else... because it broke the EL (ExpressionLanguage in java).

  

[Joe_Carrick]

10 hours ago, Alaskan_Son said:

Just as a reminder here, the reason Chief changed the naming rules is that user defined macros can be used as methods now.  I personally think it makes good sense and I just adjusted my naming conventions to suit.

FWIW, I now name my macros using lowercase but almost all of my existing macros (several dozen) were capitalized and in I retain those names - even when I make edits.  When I need a "method" I define it as such in an "rb" file which can be loaded and is then available for use within any other macro.

 

[KirkClemons]

Camel case is still an accepted standard and is a nice way to handle names that have multiple words in them.

areaRounded or roundedArea should still work so long as the object the macro is evaluating has a readable area.

[Joe_Carrick]

11 minutes ago, KirkClemons said:

Camel case is still an accepted standard and is a nice way to handle names that have multiple words in them.

areaRounded or roundedArea should still work so long as the object the macro is evaluating has a readable area.

Kirk,

 

AreaRounded or RoundedArea will also still work so long as the object the macro is evaluating has a readable area.

I just don't like the software unnecessarily forcing this on me.  It's OK to tell me (with my ability to over-ride the message) but it's not cool to force a convention that I don't want.

 

[KirkClemons]

I understand, and a power user such as yourself would understand whether or not your macro is defined as a constant or a class when you call it from another macro:

https://www.techotopia.com/index.php/Understanding_Ruby_Variables#Ruby_Constants

https://www.techotopia.com/index.php/Ruby_Object_Oriented_Programming#Defining_a_Ruby_Class

 

However, for the users who are not as familiar, it's safer (IMO) to lead them down a more specific road that sticks to the language's naming conventions more strictly so they have a better overall experience.

 

So, maybe, some general feedback to our development team on making different types of macros (i.e. Class, Constant, or Method) available in the software may be needed? 

[Joe_Carrick]

Hi Kirk,

 

I just reviewed both of those links and neither of them specifically identify a required upper/lower case requirement.  As far as "methods" are concerned, I use define them as Class Methods as the first link shows. 

 

User macros that act as "Methods" would still need to be used carefully within other macros simply because they need to belong to the same "Class" and that requires the user to understand that fact.  IOW, a "Method" that performs math calculations must use variables that are limited to numeric values and one that performs string manipulation must use string variables, etc.

 

Ruby already includes virtually all the Classes and corresponding Methods such that defining additional macros to act as Methods is just not needed.

 

I would be far happier with Chief providing all the Object Properties as available attributes.  X11 has improved this with the groups (arrays) for Walls, Floors, Ceilings and Roofs, etc but there are still hundreds of values we can't access.

[KirkClemons]

It's found under this text.

[MarkMc]

Joe I can understand why it is a PIA for someone like you that has a lot of macros and likely more than a few that reference others. I'm with Michael on this, just changed those I needed mostly as they came up (granted I don't have nearly the number you do) and continued as suggested.

Most of the better reference I've run into concurs about lower case for methods those and those that don't explicitly suggest using lower case still do in all examples- excerpt from the "Programming Ruby The Pragmatic Programmer's Guide" I'd be surprised if you hadn't come across it in your readings.

Quote

Defining a Method

As we've seen throughout this book, a method is defined using the keyword def. Method names should begin with a lowercase letter.[You won't get an immediate error if you use an uppercase letter, but when Ruby sees you calling the method, it will first guess that it is a constant, not a method invocation, and as a result it may parse the call incorrectly.]

OTOH I'm with you for having as much access as possible to variables.

[Joe_Carrick]

45 minutes ago, KirkClemons said:

It's found under this text.

Note that this is in reference to Classes must start with a Capital.  User Macros are not generally:

• Classes which must start with an uppercase character
• Methods which must start with a lowercase character
• Constants which must start with an uppercase character

In fact, a User Macro is just a Ruby Script that uses Ruby Classes and all their Objects.  It can even start with a special character such as the underscore.  I'm not sure how Chief's implementation of a macro as a method would fit in that scheme.

[DRAWZILLA]

All I know is I have many of Joe's macro's from a few versions back and they still work fine for me.

[KirkClemons]

2 hours ago, Joe_Carrick said:

Note that this is in reference to Classes must start with a Capital.  User Macros are not generally:

• Classes which must start with an uppercase character
• Methods which must start with a lowercase character
• Constants which must start with an uppercase character

In fact, a User Macro is just a Ruby Script that uses Ruby Classes and all their Objects.  It can even start with a special character such as the underscore.  I'm not sure how Chief's implementation of a macro as a method would fit in that scheme.

 

In X10, we can now call other macros as methods. This means that the naming conventions need to be enforced so that the Ruby interpreter handles them correctly. To me, that seems like another reason that we may want to expose more user control over a macro 'Type' so that Chief can handle them accordingly.

[Joe_Carrick]

16 minutes ago, KirkClemons said:

In X10, we can now call other macros as methods

Yes, I know that but I'm not sure why this needed to be done.  Was it primarily for the Materials List?

 

Note that the Ruby Tutorial is a method that's loaded by Chief at startup.  This is created within an "rb" file using standard Ruby "method definition".  As I stated previously, any methods that need to be created can (and IMO should) be done specifically as Class Methods by defining them as such.