Jump to content

Use of Different Function Format


ptrex
 Share

Recommended Posts

Why does AutoIT not accept a DOT (.) separated function syntax ?

Example of what I mean :

#include <SQLite.au3>

Func SQLite.Exec()
 ......
EndFunc

I wanted to start making to use this syntax for UDF functions.

Syntax is IncludeName.FunctionName()

But AutoIT does not like it.

Maybe you guys don't either. But I do ?! :)

Edited by ptrex
Link to comment
Share on other sites

@Nfwu

Why is that ?

If you have unique identifiers there is no confusion.

In COM call you define you identifier yourselve, so where is than the confusion ?

Like $oExcel = ObjCreate( ...)

The identifier is $oExcel

So If you create your UDF's yourselve, and you create the COM variables yourselve.

I cannot see any confusion comming up ? :)

Unless someone confuses himselve, which sometimes happenes !! :(

Link to comment
Share on other sites

OK I see some like it some don"t.

Why not let it up to the programmer what to use.

But at the moment there is even NO option ?

My question is, is the blocked by design in AutoIT.

And if so could it be discussed to be an alternative to give to those who want to use it ? :)

Link to comment
Share on other sites

@Icekirby1

No idea if that is needed ? Never used import/using etc ...

@Valik

1. Structural, easier to debug

While reading a script, and looking at the function names, you can situate where the function is comming from.

If a function is located in an include, it would be obvious which one, by reading the prefix.

You can still use the _ to start a function with, in order to distinguish from COM related stuff.

Like this _SQLite.Execute() would mean a function comming from the Included SQLite

2. Conceptually

This syntax show the RELATION between a function and an Include.

3. Visually, it looks better in SciTE

$ador.Fields.append ($field1, $adVarWChar, $MaxCharacters)

Easier to trace than this

 _ador_Fields_append ($field1, $adVarWChar, $MaxCharacters)

Type it in to see for yourselve for those who have never used COM objects coding

There is no functional advantage in this. Just a conceptual and organizational avantage.

This is how I would organize my functions if I had the possibilty to do so.

cu

Link to comment
Share on other sites

You're asking for namespace support which has already been covered using the member-selection operator in most languages. You want a feature AutoIt doesn't need implemented using a character that already has a programming connotation that even AutoIt itself already uses.

Don't you see anything wrong with that?

Link to comment
Share on other sites

@Valik

You want a feature AutoIt doesn't need implemented using a character that already has a programming connotation that even AutoIt itself already uses.

Don't you see anything wrong with that?

Are you saying it is already possible, but I am doing it wrong somehow.

Or do you mean, You see some music in my suggestion and it will be made possible sometime from now ?

Edited by ptrex
Link to comment
Share on other sites

SQLLiteOpen

SQLLite_Open

Are the same thing as:

SQLLite.Open

SQLLite::Open

So why do you think the language has to explicitly support a feature via a designated operator when you can just use good naming and achieve the same effect?

Look through the standard library for AutoIt. Look at the function names. I best you can tell where the functions come from.

Link to comment
Share on other sites

@Valik

you can just use good naming and achieve the same effect?

1. Structural, easier to debug

Not with the current naming convention. Because there is none. Everyone does what he please.

2. Conceptually

No relation is avalable on site, while everyone does what he pleases.

3. Visually, it looks better in SciTE

Not show up like COM sytax.

Look through the standard library for AutoIt. Look at the function names. I best you can tell where the functions come from.

Here you are hitting the ball wrong.

Like you say, you will have TO GO there and look.

In the systax I propose you don't need to GO THERE because it is VISUALLY clear where it comes from.

@Icekirby1

The dot syntax is just a pain to implement and has no advantage over underscores in a name or no marker at all.

How can you tell if you never used it !! :D

Read the avbove items again and test it, to see see the advantage for yourself.

Again there are personal point of views, with a background of improving where we can.

If you doubt that this is of any benifit. Than I would say, get rid of the USER DEFINED FUCNTIONS STANDARDS as well. Because this discussion is exactly of the same nature.

But I can't convince you all, since at the moment there is no a change to dos so. As long as it not possible in AutoIT.

Link to comment
Share on other sites

@ptrex

I think that what is being said is that the "." doesnt have any actual functional difference to the code. You cannot force anyone to write their code a certain way. (Sometimes a good thing, sometimes bad)

If you think the standard UDF's should have a certain Naming structure I would bring that up to JdeB. He would be the one to set that up.

I do like how you are doing the _SQLite_FuncName() functions... its a bit of a pain to type that long as I rarely use but maybe one or two includes per script.

JS

AutoIt Links

File-String Hash Plugin Updated! 04-02-2008 Plugins have been discontinued. I just found out.

ComputerGetInfo UDF's Updated! 11-23-2006

External Links

Vortex Revolutions Engineer / Inventor (Web, Desktop, and Mobile Applications, Hardware Gizmos, Consulting, and more)

Link to comment
Share on other sites

@JSThePatriot

Naming structure I would bring that up to JdeB

There is nothing to bring up ?! Standards are already been imposed. :D

UDF Standards

its a bit of a pain to type that long

When using the DOT separated syntax, everyone would think more about the naming convertions.

Instead of just typing along.

CU around

Link to comment
Share on other sites

1. Structural, easier to debug

Not with the current naming convention. Because there is none. Everyone does what he please.

As JS already mentioned, that isn't going to change. People have been using stupid/no naming conventions since the dawn of time. Nothing is ever going to change that.

3. Visually, it looks better in SciTE

Not show up like COM sytax.

This is completely subjective. I also fail to see how you can make any assertions on what it does/will look like since the lexer doesn't support the notation. It supports a period being the separate from a COM object and the method/property but it does not support the period being a namespace resolution operator.

Here you are hitting the ball wrong.

Like you say, you will have TO GO there and look.

In the systax I propose you don't need to GO THERE because it is VISUALLY clear where it comes from.

You are the one who missed the point, not me. I meant I wanted you to go there right now and look at the files to see that you already can identify quite clearly where they come from if you encounter library functions in source code. It was me making a statement of something you needed to do for yourself before you responded on this subject again. For example, look at the function name "_GUICtrlListViewCopyItems ". Knowing AutoIt's naming conventions, I see the leading underscore and know it's a library function, not a built in function. Then I scan along the name and I see "ListView" in the name. Okay, so it's a list-view related function. Looking at the library files, I see a "GUIListView.au3". At this point I'd be willing to be money that the ListView functions are in the ListView file.

So I ask you one more time. What can you do with a period that you can't do with an underscore or casing? In addition, your first comments in the reply I quoted suggest to me some displeasure with the ad-hoc manner in which functions are named. However, AutoIt already has a naming convention that is consistent across both built-in functions as well as standard library functions. So your proposed notation is not only unnecessary, it's actually the enemy of the naming convention already established.

Link to comment
Share on other sites

@JSThePatriot

There is nothing to bring up ?! Standards are already been imposed. :D

UDF Standards

When using the DOT separated syntax, everyone would think more about the naming convertions.

Instead of just typing along.

CU around

I know standards are already being imposed for the UDF Includes... if you dont want your UDF included you dont have to follow those standards.

What I was mentioning is that if you wanted those standards changed that you would need to speak with him as he is the one that setup the UDF standards though he based them on AutoIt naming standards.

I am actually always thinking about naming standards. I always wonder why someone named a variable a certain way. I still have yet to find the "standard" that I like to follow. With any UDF I submit I do create it with the UDF Standards. For my own functions I do differ slightly as you can see on my recent support post.

JS

AutoIt Links

File-String Hash Plugin Updated! 04-02-2008 Plugins have been discontinued. I just found out.

ComputerGetInfo UDF's Updated! 11-23-2006

External Links

Vortex Revolutions Engineer / Inventor (Web, Desktop, and Mobile Applications, Hardware Gizmos, Consulting, and more)

Link to comment
Share on other sites

@JS

if you dont want your UDF included you dont have to follow those standards.

I am sorry to say that it is not the case. Try to make a function using a DOT.

You can"t run the script. At least I can't.

@Valik

What do I like discussing with you :D

Whenever I think he is not going to reply on this one, your replies get longer and longer. lol

This is completely subjective

Ofcourse this whole discussion is subjective, and that is what it will erver be.

That is infact inherent to any standards defined !!

lexer doesn't support the notation

I realy think you are from an other world, or you are using special lexer !!

If I type this

AutoIt.standards()

in SciTE I see clearly on other visual effect than this "AutoITstandards"

It is not wether it is supported now or not. That is besides the point at this moment in time.

Knowing AutoIt's naming conventions

Again this is partly besides the point. Most UDF's written are not in compliance with this naming converion.

This if you scan along those ones you will never see what you are looking for.

When the dot syntax is support, coders will see immediately the visual effect of it (if supported by the lexer). And this will be much more stimulating to comply with. What I see with my eyes, will be much faster absorbed, than what I have read somewhere. And that goes for a lot of people (in fact for all of them).

AutoIt already has a naming convention that is consistent across both built-in functions as well as standard library functions

I respect that. But why not open the door for putting a dot in a function, for at least those what to put it there.

And I can assure you AutoIT will not be the first language that does it.

Have a nice weekend.

Edited by ptrex
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...