New post
Question
· Jun 3, 2019

Autocomplete in Cache Studio Client 2016.2

#Studio #Caché

hi, i am new to Studio and also new to objectscript, but i am not new to programming and

want to implement some synonymfunctions e.g.  LOCATE should be used as InStr (.. like in much languages ;o)

 

more generally spoken, i want to implement a library for my string routines BUT of course i want an need autocomplete.

defining a macro $$$InStr does no autocomplete  when i type $$$In<CTRL-SPACE>

 

example: my lib is called STRINGS and the functions are: InString, Split, ...

when i type STRINGS.       it should autocomplete

i also don't want to write  ##class(xxxxx.yyyyy).InString()   every time.

so how can we write less and get most out of autocomplete?

 

thx, reinhard

Discussion (8)1
Log in or sign up to continue
Eduard Lebedyuk · Jun 3, 2019

Great points, Sean.

However there are, I think, areas where macros are needed:

  • Compile-time execution (if it's possible to resolve stuff at compile time, do it)
  • Constants/Enums
  • Trivial wrappers over system functions (i.e. I use $$$ts instead of $zdt($h, 3, 1, 3) because it's everywhere)

But I definitely agree that overabundance of custom macros makes code unreadable.

0 0
Sean Connelly · Jun 3, 2019

Hi Reinhard,

Welcome to ObjectScript and the Community.

As you are still learning ObjectScript I hope you don't mind a small amount of extra guidance on what you are doing.

I can understand why a set of popular named string functions might be a good idea, but in practice there are enough differences across languages to make one solution feel familiar to one set of developers and not to another. For instance InStr() might be familiar to Visual Basic developers but Java and JavaScript developers would be expecting indexOf() and Python developers find().

In general abstracting ObjectScript string operators and built in string functions with Macro's is going to produce a non standard solution. Whilst you will be an expert in Reinhard String Functions, you won't be a fully grounded ObjectScript developer and the code you produce will be less readable and maintainable to those that are.

Learning native string operators and built in functions is an important step in becoming a competent ObjectScript developer and its really worth the investment to build these important foundations in your new language skillset. In practice there are very few operators and string functions to learn and the required investment will work out less than developing and unit testing your own library. That's not including the time to write bespoke documentation that other developers would then need.

I can also understand why auto complete goodness might also look like a useful asset in this process, but as soon as you are fluent in ObjectScript foundations, the code will just be streaming off your fingertips, and constant pop up suggestions would just be a distraction.

A few more things to consider. Overuse of Macro's can lead to a condition I call Macro Soup. The more Macro's that are used, the less readable code will become. If you start including very common functions such as strings then you will soon hit this problem. It's great to see you are already exploring these powerful features of ObjectScript, but IMHO its best to be non liberal in using them.

You might also be interested to know that InStr() is actually supported in Caché, both in its SQL dialect and with the Caché Basic transcompiler. If for instance you are a Visual Basic developer shop and will continue long term recruitment from this skills pool, then Caché Basic might make more sense to you. That said, you will never be fully rounded without also being able to read compiled ObjectScript as well.

One last recommendation I always give when teaching ObjectScript is to write your own cheat-sheet. The process itself tends to solidify knowledge more quickly and having the cheat-sheet on hand will help to jog your memory.

Have fun learning!
Sean.

2 0