Declaring an empty array

[enaiman]

I really can't understand what prevents you guys to write a similar function (_ArrayAdd...whatever) to behave the way you like it. PhilHibbs gave a good example in this thread - use that one for God's sake; you can even make it better.

What is the purpose of so much arguing? You are talking to someone who is developing AutoIt. Don't you think his programmer experience is much bigger than yours? That he knows what he's talking about? Why don't you show a little respect to believe what he is saying?

There are many times when I can't agree with Valik; when his answers to some posts seem to me to be very harsh and rude but when it comes to his competence - I never doubt it. On the other hand he is a moderator on this Forum - like it or not, this is not a democracy and the mods have the power to allow or deny access; if people really enjoy being around here then wouldn't be a good idea to start pissing the mods off. They have to deal with alot of crap everyday so they might be on the edge most of the time.

We aren't real-life friends with them, they can't "know" us and if we get on their "bad-side" do you think we'll get second chances? Maybe we will maybe not - are we really prepared to find out?

I'm directing this at you @dani because you seem like an educated and reasonable guy (one of your early posts in this thread showed that very well) but you still continue this argument ... I only hope you will stop when it's not too late.

[czardas]

Use the tools you already have, or create your own tools. I would like to be able to add and remove dimensions from arrays, but that has to be hand coded because the function is not (or not currently) implimented in the language. I would be curious to know which languages allow the appending of dimensions to an array BTW. Whether it exists or not, there are ways around it. I would prefer functions to be as simple and straight forward as possible, then there is less chance of things going wrong, even if it requires a bit more effort on my part.

So now we have data types:

Empty Strings

Empty Arrays

Arrays with zero dimensions

Just get on with it and stop blaming the tools!

[GEOSoft]

The solution is just far too simple. If you don't like the way things are done with AutoIt then don't use it. How much simpler can it get?

I agree whole heartedly with enaiman about the arguing with any member of the Dev team. That can only end in a bad way unless you voluntarily stop first.

There is a feature request function on Trac, you use that and it either gets accepted or rejected but either way it's over and done with.

Developer Chat is not the place to ask for features to be added or removed nor is it the place for pointless arguments so the smart ones will let it die here and now.

[Valik]

Please don't encourage people to waste more of my time by creating feature requests I'll just have to close when it's clear from the thread that it's not going to happen and if it does happen it will be a "free" feature that comes along with another one (which I linked to).

[GEOSoft]

Please don't encourage people to waste more of my time by creating feature requests I'll just have to close when it's clear from the thread that it's not going to happen and if it does happen it will be a "free" feature that comes along with another one (which I linked to).

Sorry Valik. It wasn't really intended as encouragement.

[dani]

I really can't understand what prevents you guys to write a similar function (_ArrayAdd...whatever) to behave the way you like it. PhilHibbs gave a good example in this thread - use that one for God's sake; you can even make it better.

What is the purpose of so much arguing? You are talking to someone who is developing AutoIt. Don't you think his programmer experience is much bigger than yours? That he knows what he's talking about? Why don't you show a little respect to believe what he is saying?

There are many times when I can't agree with Valik; when his answers to some posts seem to me to be very harsh and rude but when it comes to his competence - I never doubt it. On the other hand he is a moderator on this Forum - like it or not, this is not a democracy and the mods have the power to allow or deny access; if people really enjoy being around here then wouldn't be a good idea to start pissing the mods off. They have to deal with alot of crap everyday so they might be on the edge most of the time.

We aren't real-life friends with them, they can't "know" us and if we get on their "bad-side" do you think we'll get second chances? Maybe we will maybe not - are we really prepared to find out?

I'm directing this at you @dani because you seem like an educated and reasonable guy (one of your early posts in this thread showed that very well) but you still continue this argument ... I only hope you will stop when it's not too late.

I know you are right. I would have backed off already but I saw other people also responded and Valik moved it to Dev so I guess we could continue the discussion in a normal manner. Sadly, Valik decided to start reacting over-the-top again using language that would probably get me banned when used against him.

I will stop the arguing over the empty array now. One thing I want to react to though:

Stop, take your "empty arrays are the only way" hat off and realize how you would write code in both cases.

That is the exact opposite of my philosophy. How can you say that? I'd like there are many ways to do something, let the user decide. It is already possible using code you posted, Melba posted, etc. It's just not yet possible using the method of the empty array. In my opinion, moving checks away from the user is a good thing but I will (finally ) accept we disagree on that.

Please just stop being offended by my posts. In no way I want to offend you or disrespect you or anyone for that matter. Clearly you feel I disrespect you when I propose something which you believe does not make any sense. I hope you understand that is not my fault -- people have opinions, I will never apologize for having one. Let's just bury the hatchet, shall we?

[PhilHibbs]

I will stop the arguing over the empty array now... Let's just bury the hatchet, shall we?

Ditto - as a point of reference, I made the ticket before seeing this thread. I searched for posts relating to _ArrayAdd and _ArrayDelete before posting the ticket and didn't see any relevant, but didn't spot this thread. It may look from my post here as if I saw the debate about empty arrays and decided to add fuel to the fire by raising a ticket, but that's not how it happened. Edited March 12, 2010 by PhilHibbs

[doudou]

Did you read my statement? I said empty arrays don't make sense, not that they aren't possible. Everything you can do with an empty array I can do without such a feature. Do you know what an empty array is? It's syntactic sugar. It's mere convenience. It means you can do lazy initialization on arrays. Show me an example of code where you are absolutely convinced beyond a shadow of a doubt that it can't be done without an empty array. I'll show you how to do it. Keep in mind, I'm talking about POD arrays here and ideally AutoIt specifically. I'm not talking about languages where the supposed empty array is really an object with methods and properties.

Wow! This is certainly the most polemical defense of a concept I've ever heard: a feature makes no sense because it is mere convenience. Valik, virtually everything in a programming language with higher level of abstraction is mere convenience. Every program with any functionality can be written in plain assembler, does it mean we don't need functions, structures, classes and all other "syntactic sugar" provided by higher languages? I don't think so and I simply don't believe, it is really your opinion if you are honest.

The only absolute truth is there are no absolute truths. However, I will say this. My statement is truth so-long as the goal of the language isn't to prove the statement false. There are a few language design decisions that can be made where empty arrays are required. However, such design decisions would be deliberate with the specific intent to disprove my statement. In none of the languages cited so far (including AutoIt) are empty arrays necessary. Useful for convenience? Perhaps. But required? No.

And again: nothing beyond assembler is required to write a program.

I understand that it is the author's freedom to make whatever design decisions he/she finds appropriate. But having these decisions questioned by others you aren't being fair answering with the argument of the kind "I know it better, so shut up", it is not real argument but a provocation.

For my part I already got used to impossibility of empty array creation in AutoIt. Do I miss the feature? Yes. Would it make array handling code cleaner and easier to read? Of course. Would it make transition from other languages for AutoIt beginners easier? Sure. Are these legitimate reasons to revise the decision against the feature? IMHO yes, they are. But I can live without it.

Also, to address a point in your first quote, if I'm so alone, why is it statically typed languages (or at least C and C++) don't allow empty arrays?

Well, this is not quite true.

C doesn't actually know arrays as a type, arrays here is just a convenient (here it is again) method to allocate space for multiple variables at once. This code in C:

int array[] = {1, 2};

is equivalent to this:

int* array = (int*) malloc(sizeof(int) * 2);
*array = 1;
*(array + 1) = 2;

In C++ empty arrays are on the other hand indeed possible:

vector<int> array;
cout << array.size(); // outputs 0

Edited March 12, 2010 by doudou

[Valik]

doudou, all credibility of your post is completely lost when you bring up a vector. A vector is an object. It has methods and properties. It is not a POD type. Furthermore, a vector is an example of exactly what I'm advocating. The nasty implementation details (which are completely irrelevant to a std::vector user, by the way) are hidden away behind an interface. It is not possible in native C++ to have an empty array, but it is possible to write or use a library that provides a class which implements the functionality. Much like the List interface I gave as an example above.

As for the rest of your post, well, you're right, but only because you've taken the strawman argument route. I hardly think the presence or lack of empty arrays is a fundamental obstacle preventing people from learning the language. The difference between learning assembler and a higher level language is much greater than the difference between learning a higher level language with empty arrays versus one without empty arrays. It's more important that something can be done rather than how it's done. The beautiful thing about languages supporting functional programming is we can write functions to hide all those nasty bits we don't like to use or look at.

As for you, dani:

That is the exact opposite of my philosophy. How can you say that? I'd like there are many ways to do something, let the user decide. It is already possible using code you posted, Melba posted, etc. It's just not yet possible using the method of the empty array.

As I said above, it's more important something can be done, not how it's done. Functions make the world a better place.

In my opinion, moving checks away from the user is a good thing but I will (finally ) accept we disagree on that.

Moving what checks away from the user? Nothing is moved away from the user. The user must still ensure their array index is valid. I'm not sure what you are referring to, unless you are still trying to refer to _ArrayAdd() which is again failing to acknowledge that perhaps _ArrayAdd() isn't as well written as it could be (rather than claiming the language isn't).

Please just stop being offended by my posts.

Please stop trying to tell me what I should or should not feel. I'm not offended, I'm annoyed that it's taken so long to get through to you the banality of this feature you seemingly feel is so critical. If I've even gotten through. Also, it annoys me that you disregard Melba (at least) and that you refer to any method but the empty array method as a "workaround" which is a really poor choice in terminology given that in AutoIt it's not a workaround, it's how you bloody well do ti.

[doudou]

doudou, all credibility of your post is completely lost when you bring up a vector. A vector is an object. It has methods and properties. It is not a POD type. Furthermore, a vector is an example of exactly what I'm advocating. The nasty implementation details (which are completely irrelevant to a std::vector user, by the way) are hidden away behind an interface. It is not possible in native C++ to have an empty array, but it is possible to write or use a library that provides a class which implements the functionality. Much like the List interface I gave as an example above.

Just for the sake of argument: in C++ anything on the left to a variable declaration is a type, virtually no difference exists between "native" and custom types. And this is the breaking point in your comparison between C++ and AutoIt - in AutoIt script developer has to live with the types provided by the language, he cannot define his own. Even UDFs offer no real workaround because it is not possible to submit an empty array as a parameter to a function (nor there's anything like NULL pointer in C) to indicate: here comes an array that wants to be filled. If we want _ArrayAdd() and _ArrayDelete() to behave consistently additional opaque calling contracts have to be defined like "empty string stands for empty array". Edited March 12, 2010 by doudou

[Valik]

Just for the sake of argument: in C++ anything on the left to a variable declaration is a type, virtually no difference exists between "native" and custom types. And this is the breaking point in your comparison between C++ and AutoIt - in AutoIt script developer has to live with the types provided by the language, he cannot define his own. Even UDFs offer no real workaround because it is not possible to submit an empty array as a parameter to a function (nor there's anything like NULL pointer in C) to indicate: here comes an array that wants to be filled.

You are bound by arbitrary rules and lack imagination to see around them. I'm sorry for that. All I can offer in response is I'm not bound by such silly rules so I don't have such a narrow view on things. The way types are constructed and used isn't quite the same as they are in C++ or some other languages but that certainly hasn't stopped me from creating my own types in AutoIt for years. The only major downside to the way types are created in AutoIt is that there is no compile-time type-checking. It requires a little more care on the part of the user to ensure the type's invariants aren't being violated. I think I've demonstrated quite clearly in my previous post how to create a list type.

Is the syntax different? Sure. Is the functionality different? No.

If we want _ArrayAdd() and _ArrayDelete() to behave consistently additional opaque calling contracts have to be defined like "empty string stands for empty array".

I'm not sure what you mean by "opaque calling contract". I can't tell if you mean the calling contract is supposed to be clear to the user or if the user isn't supposed to know or care about the calling contract. The reason for the confusion stems from the term "opaque handle". My List implementation above uses an opaque handle. You receive a handle from ListCreate() and pass it to all the other List* functions. What the handle is actually composed of is irrelevant. To attempt direct element access on the handle directly is improper use of a list (hence the reason ListGetElement() was written).

[doudou]

You are bound by arbitrary rules and lack imagination to see around them. I'm sorry for that.

LOL No, really, I always have thought of me as an imaginative person. No reason for pity.

All I can offer in response is I'm not bound by such silly rules so I don't have such a narrow view on things. The way types are constructed and used isn't quite the same as they are in C++ or some other languages but that certainly hasn't stopped me from creating my own types in AutoIt for years. The only major downside to the way types are created in AutoIt is that there is no compile-time type-checking. It requires a little more care on the part of the user to ensure the type's invariants aren't being violated. I think I've demonstrated quite clearly in my previous post how to create a list type.

Is the syntax different? Sure. Is the functionality different? No.

I don't doubt the possibility of needed functionality in AutoIt itself just because of missing empty arrays, I created and used such functionality myself on several occasions in my scripts. As I said, I can live without empty arrays. As far it concerns me you don't need to argue on this subject, your argument that empty arrays are principal nonsense and your attempt to seek justification in other programming languages have disturbed me nonetheless. 1-ly, one can show that the empty array concept is widely common and 2-ly, convenience and transparency of use are very reasonable arguments in favor of a programming language feature.

I'm not sure what you mean by "opaque calling contract". I can't tell if you mean the calling contract is supposed to be clear to the user or if the user isn't supposed to know or care about the calling contract. The reason for the confusion stems from the term "opaque handle". My List implementation above uses an opaque handle. You receive a handle from ListCreate() and pass it to all the other List* functions. What the handle is actually composed of is irrelevant. To attempt direct element access on the handle directly is improper use of a list (hence the reason ListGetElement() was written).

By "opaque" I meant that if a function expects an array but under certain circumstances (array is empty) the type of expected parameter suddenly changes, it is not transparent for the caller and provokes (unnecessary) errors. And it wasn't connected to your List UDF.

[PhilHibbs]

If anyone wants "empty array" functionality, here it is. Just use these functions instead of _ArrayAdd. Make sure that your second dimension (the length of the second array parameter) is consistent in _ArrayAdd2, or you will might lose data. To start with an empty array, just declare the variable without Dim, you can initialize it to "" if you want as that is what _ArrayDelete does when an array loses its last element.

Func _ArrayAdd1( ByRef $avArray, $vValue )
    Local $iUBound = UBound($avArray)
    If Not(IsArray($avArray)) Or UBound($avArray, 0) <> 1 Then
        Dim $TempArray[1]
        $avArray = $TempArray
        $iUBound = 1
    Else
        ReDim $avArray[$iUBound + 1]
    EndIf
    $avArray[$iUBound] = $vValue
    Return $iUBound
EndFunc   ;==>_ArrayAdd1

Func _ArrayAdd2(ByRef $avArray, $avValue)
    Local $iUBound1 = UBound($avArray)
    Local $iUBound2 = UBound($avValue)
    If UBound($avArray, 0) <> 2 Then
        Dim $TempArray[1][$iUBound2]
        $avArray = $TempArray
        $iUBound1 = 0
    Else
        ReDim $avArray[$iUBound1 + 1][$iUBound2]
    EndIf
    For $i = 0 To $iUBound2 - 1
        $avArray[$iUBound1][$i] = $avValue[$i]
    Next
    Return $iUBound1
EndFunc   ;==>_ArrayAdd2

If you need more than two dimensions, then you will have to extend _ArrayDelete to cope with it, and write an _ArrayAdd3 function based on the above.

Edited March 16, 2010 by PhilHibbs

[dani]

Is the syntax different? Sure. Is the functionality different? No.

I don't doubt the possibility of needed functionality in AutoIt itself just because of missing empty arrays, I created and used such functionality myself on several occasions in my scripts. As I said, I can live without empty arrays. As far it concerns me you don't need to argue on this subject, your argument that empty arrays are principal nonsense and your attempt to seek justification in other programming languages have disturbed me nonetheless. 1-ly, one can show that the empty array concept is widely common and 2-ly, convenience and transparency of use are very reasonable arguments in favor of a programming language feature.

This is the heart of the problem I believe. Valik, you are not the only one who knows that adding some convenience will not change the functionality. I know this, doudou knows this and frankly I think most people do. This is not something I was questioning, contrary to what you seem to believe I am not stupid

Neither was I implying it is some kind of fundamental obstacle in any way, I am not sure where you got this. I seem to be on the exact same page as doudou on this one. It makes programming AutoIt more convenient in some situations (for me, at least), so I wondered why it was left out.

I now understand that in your philosophy, added convience is not important enough for things to change if the functionality is already present in a (for some people) less convenient way. So I completely understand why we might be annoying considering this opinion, but I hope you can also understand our (at least mine and doudou's) reactions when you consider our view on this.

[Valik]

dani, it's a combination of your persistence to get a "satisfactory" answer as well as some of the terminology you've used throughout implying the AutoIt method is in some way inferior.

[doudou]

dani, it's a combination of your persistence to get a "satisfactory" answer as well as some of the terminology you've used throughout implying the AutoIt method is in some way inferior.

Supposed I'm not fishing for "satisfactory" answers and not implying anything, may I - out of pure curiosity - ask you an intimate question Valik?

What is the real reason behind your opposition against empty arrays? Is there some serious technical catch in implementation of AutoIt that would make this extremely expensive (in whatever way)? Or is it your personal repulsion towards the idea itself?

[Fulano]

All due respect to the parties involved, but it seems like dani and co. are asking why AutoIt's Arrays aren't Linked Lists, and Valik & etc are trying to explain why they aren't.

If you want the ability to add and remove elements cheaply (in terms of time), then go ahead and make a Linked List UDF and be done with it.

If you want the speed of accessing elements by array offset, then pay the cost of thinking ahead.

Using an array as a linked list makes no sense and makes life more complicated.

Calling them both arrays just creates headaches.

[dani]

@Fulano

If I wanted to know why AutoIt's Arrays aren't Linked Lists I would have asked that question. So with the same respect to you; no I did not want to know that

dani, it's a combination of your persistence to get a "satisfactory" answer as well as some of the terminology you've used throughout implying the AutoIt method is in some way inferior.

Ah so the problem is more complicated than I thought Yes you are right, I did imply the AutoIt method is inferior in some way; namely convenience. I think it's less convenient to use proposed methods than starting with the empty array. I am quite surprised the simply fact I question a tiny part of AutoIt and have the opinion the current way is slightly inferior is enough for you to respond in the harsh and plain rude ways you did. It really is user feedback in its purest form (a user's opinion about the product -- AutoIt). How can you blame and insult a user for posting some feedback is beyond me.

[Valik]

What is the real reason behind your opposition against empty arrays? Is there some serious technical catch in implementation of AutoIt that would make this extremely expensive (in whatever way)? Or is it your personal repulsion towards the idea itself?

We do not need it. There's no need messing with the files - especially complex, core files - without a need to do it. The last time I personally touched one of the files where something like this was implemented was to add the comment "There be dragons in here" as a sort of warning to the other developers to stay the fuck out and don't mess with the code. It was essentially a comment from Jon I made manifest.

Adding features for the sake of adding features is stupid and is prone to back-firing. If we are going to work in that area anyway (as would be necessary to implement the ticket I linked to previously), then fine, whatever, it's essentially free behavior with the feature requested in that ticket, anyway.

Ah so the problem is more complicated than I thought Yes you are right, I did imply the AutoIt method is inferior in some way; namely convenience. I think it's less convenient to use proposed methods than starting with the empty array. I am quite surprised the simply fact I question a tiny part of AutoIt and have the opinion the current way is slightly inferior is enough for you to respond in the harsh and plain rude ways you did.

You want to call rudeness on my part? How about how you treat me? I don't particularly like being incessantly questioned when I've given an answer. I don't particularly like wasting my time answering the same question and then further explaining it ad nauseum because one or two people aren't content with my answers. I don't particularly like having to explain myself when the best argument against my position is "but other languages let you do it".

If you want examples of my rudness towards people then search the forum. You'll find plenty. You? You have gotten off without a scratch. Perhaps with less than you deserve, in fact. So don't you dare come to me trying to play the "rudeness" card or I'll show you rude.

It really is user feedback in its purest form (a user's opinion about the product -- AutoIt). How can you blame and insult a user for posting some feedback is beyond me.

Feedback is one thing, incessantly questioning me over something is another entirely.

Now, are we quite done with this thread or is there some other asinine minutia that must be discussed until we're all very tired of it?

Edit: IM conversation between Jon and I. My comment about modifying scriptfile_lexer.cpp was a joke to provoke a reaction due to previous parts of the conversation:

Valik:  Maybe instead of sleep I should find something to do in scriptfile_lexer.cpp or something.
Jon:    There be dragons in there
Valik:  Oh, I am so going to make a change to the file now.
...
Valik:  Revision 5614 committed.
Jon:    >.<

Log for revision 5614:

Revision: 5614
Author: Valik
Date: Wednesday, January 20, 2010 6:06:20 AM
Message:
Added: Very important comment.
----
Modified : /trunk/shared/src/scriptfile_lexer.cpp

Unified diff of actual changes:

Index: scriptfile_lexer.cpp
===================================================================
--- scriptfile_lexer.cpp    (revision 5613)
+++ scriptfile_lexer.cpp    (revision 5614)
@@ -40,6 +40,8 @@
 //
 // Provides lexing (string into tokens). Part of script.cpp
 //
+// There be dragons in here
+//
 ///////////////////////////////////////////////////////////////////////////////

That was the last time the file was touched.

Edited March 17, 2010 by Valik

[doudou]

Now, are we quite done with this thread or is there some other asinine minutia that must be discussed until we're all very tired of it?

Me is finished: if I had a point I think I made it. To hear opinions of valued colleagues and follow their battles as unnecessary as they were entertaining was... fascinating.

Thanks for your time and thoughts, Valik.

Code fast and proper!