Besides multithreading...

[Valik]

No, I'm not missing the point of access control and I agree with you, but I find it less important in practical terms than the basic data/function encapsulation of OO. Having spent some time coding in Basic (including some horrible dialects), C, assembly and a few other languages which don't provide access specifiers, if I had to name one or two big wins from OO, access control would not be the first thing to come to mind. But of course this is a personal preference.

As I said, when the ratio of private to public methods goes beyond a certain point, splitting the class starts to look like a good idea, usually producing a pair of interfaces with all public methods. Having one class with an uncomfortably large and growing number of public methods is also a code smell and would probably lead to the same refactoring.

You are grossly underestimating the important of access control by failing to look at what access control really does: It forces clients (specifically: you) to adhere to good data/function encapsulation (as you put it). If you declare things with the correct access specifier then the compiler will flat out say "no, you can't do that" which means you won't even try because you know the compiler won't let you. Were you in the habit of using public members/methods all the time you would start skimping on declaring proper API's around those members and begin short-cutting the methods as well. Access control isn't something you generally think much about since it's pretty obvious whether something is public or private. In C++ it only gets a little thought when you add protected into the mix.

I write object-oriented AutoIt code, I just do not have object-oriented notation to go with it. I encapsulate my data as much as I can by using arrays for storage and functions that manipulate the data in the array. The problem with this approach (Aside from lacking convenient syntactic notation) is that data is not protected at all. It is possible to interact with the data directly. The second problem is the lack of compiler-enforced access control means I can be lazy if I want to which results in less rich and less resilient interfaces.

I'm not saying that access control is the most important feature an object-oriented language has. What I am saying is that access control is a very subtle feature that not only affects the way the compiler works but the overall mentality of the programmer as well. It's benefits should not be discarded just because it's not as flashy as dot notation.

[exolon]

I write object-oriented AutoIt code, I just do not have object-oriented notation to go with it. I encapsulate my data as much as I can by using arrays for storage and functions that manipulate the data in the array. The problem with this approach (Aside from lacking convenient syntactic notation) is that data is not protected at all. It is possible to interact with the data directly. The second problem is the lack of compiler-enforced access control means I can be lazy if I want to which results in less rich and less resilient interfaces.

When I mentioned the bureaucracy of access control, I was focusing in particular on access specifiers for methods. I'd certainly agree that a more strict encapsulation of member variables lends itself to better programming - I mentioned closures earlier because they come in handy for me in some languages (i.e. Lua, Scheme) by rolling your own OO, having member variables stored in an object's (really just a table of functions referencing variables local to a scope which is otherwise inaccessible) closure, so the only way to interact with that data is by adding getters/setters.

So data encapsulation/protection, yes, because the dangers if you don't are rather obvious. Where I take some issue is with the popular notion that the choice whether to make a couple of methods private or public will make the difference between awful and excellent code(rs) - that seems overhyped IMO.

I haven't written a great deal of AutoIt code, so the end result is most definitely not OO-like and like I said sometimes messy. The project I'm currently doing only has two source files, but the functions are already much longer than methods I write in OO languages - partly because when splitting up a function, you end up with massive parameter lists as the partial states get passed about. This isn't necessary in OO, and that's what I miss most, more than access control, so it would be interesting to see what strategies people (successfully) use to keep things clean, beyond "MustDeclareVars" .

[Valik]

Why do you place more emphasis on members as opposed to methods? An incorrectly public method can fuck up a program just as easily as an incorrectly public member. I know from experience that programmers will do bad things just because they can (and they are dumb but perhaps that's a whole other can of worms).

Stop and think about what an object-oriented language does for you and then you'll realize how to keep your code clean by doing it yourself. Objects provide syntactic convenience for method and member access as well as scoping by giving a nice fancy syntax. You can do the same thing with specific naming conventions. You can't protect against all things a true object-oriented language can, but you can write code that is comparable and even quickly portable to other languages.

Below is a skeleton of a pseudo-datatype in AutoIt with proper scope and naming conventions and constants for access as opposed to traditional object notation.

; Private data structure declaration
Global Enum $BOOK_TITLE, $BOOK_AUTHOR, $BOOK_ISBN, $BOOK_MAX

; Public functions
Func BookCreate($sTitle = "", $sAuthor = "", $sISBN = "")
    Local $aBook[$BOOK_MAX]
    If $sTitle Then $aBook[$BOOK_TITLE] = $sTitle
    If $sAuthor Then $aBook[$BOOK_AUTHOR] = $sAuthor
    If $sISBN Then $aBook[$BOOK_ISBN] = $sISBN
    Return $aBook
EndFunc

Func BookDestroy(ByRef $aBook)
    $aBook = ""
EndFunc

Func BookSetTitle(ByRef $aBook, $sTitle)
    If __IsBookValid($aBook) Then $aBook[$BOOK_TITLE] = $sTitle
EndFunc

Func BookGetTitle(Const ByRef $aBook)
    If __IsBookValid($aBook) Then Return $aBook[$BOOK_TITLE]
EndFunc

; Similar methods can be written for ISBN and Author.

; Private functions
Func __IsBookValid(Const ByRef $aBook)
    Return UBound($aBook) = $BOOK_MAX
EndFunc

Sample usage:

Func Main()
    Local $oLordoftheRings = BookCreate("Lord of the Rings", "J.R.R. Tolkien")
    ConsoleWrite(BookGetTitle($oLordoftheRings & @CRLF)
EndFunc

Global $g_nExitCode = Main()
Exit $g_nExitCode

Dry-coded into the browser, may contain typos.

[exolon]

Why do you place more emphasis on members as opposed to methods? An incorrectly public method can fuck up a program just as easily as an incorrectly public member. I know from experience that programmers will do bad things just because they can (and they are dumb but perhaps that's a whole other can of worms).

I already explained my thoughts on this, but I'll try to summarise again:

• Where possible, I use test-driven design when building programs. This requires that any methods likely to need a test must be public or at least protected in Java (if the test class is in the same package). When classes start getting big I break them up rather than having a large number of private, untestable methods.
• I've been coding for long enough to develop preferences for these things, and so far, having protection for member variables rather than methods feels much more important. As I said, this is a personal preference and I don't judge you or anyone else for having different preferences.

Below is a skeleton of a pseudo-datatype in AutoIt with proper scope and naming conventions and constants for access as opposed to traditional object notation.

Thanks, this seems nice and straightforward. Is there a noticeable performance hit using arrays to hold member variables? I haven't looked for benchmarks of any AutoIT code (except for image searching libraries), but there were some surprising differences between ways of implementing OO in Lua.

[Valik]

I already explained my thoughts on this, but I'll try to summarise again:

• Where possible, I use test-driven design when building programs. This requires that any methods likely to need a test must be public or at least protected in Java (if the test class is in the same package). When classes start getting big I break them up rather than having a large number of private, untestable methods.
• I've been coding for long enough to develop preferences for these things, and so far, having protection for member variables rather than methods feels much more important. As I said, this is a personal preference and I don't judge you or anyone else for having different preferences.

Meh, if I were doing that in C++ I would use friend classes. I do not know what other languages offer in the way of similar functionality, if anything.

Thanks, this seems nice and straightforward. Is there a noticeable performance hit using arrays to hold member variables? I haven't looked for benchmarks of any AutoIT code (except for image searching libraries), but there were some surprising differences between ways of implementing OO in Lua.

Lua has built-in syntactic sugar of secretly passing a this (self) variable as well as dot notation. It also supports first class functions and "arrays" are implemented as tables which can have anything as an index which is a further bit of magic that lets it all work.

As for performance, I don't care. If I have a need to optimize for critical performance then I will, otherwise I write clean code and let improvements to the language itself provide speed increases.

[Kip]

To get back on subject: I think namespaces would be very helpful, especially to library writers and anyone who's writing bigger projects in AutoIt. Since they're pretty much a preprocessor thing, I don't see a reason why AutoIt doesn't have them already.

[Valik]

To get back on subject: I think namespaces would be very helpful, especially to library writers and anyone who's writing bigger projects in AutoIt. Since they're pretty much a preprocessor thing, I don't see a reason why AutoIt doesn't have them already.

That's a very simple answer: Because you can do it yourself. Ever wonder why all the window related functions start with "Win" or the process functions start with "Process"? It's because they are in that "namespace". That's why WinAPI.au3 functions are named _WinAPI_<Function> and so forth. Do you really need the compiler to enforce namespaces on you? Do you lack the discipline to do it yourself? Further, namespaces are not trivial to implement since AutoIt only has 2 scopes: Global and Local. Namespaces would add in another scope. Then it wouldn't be long until people try to abuse namespaces to create "objects" and then we come right back around to people wanting true objects.

The tl;dr version is do it yourself because I don't want to deal with the several cans of worms attempting to add it will open.

[Skitty]

If programming languages were animals, autoit would be the tortoise.

If autoit was a human, it would be the midget with 3 amputated limbs.

If autoit was a car, you'd have to stop and turn it off in order to steer left or right.

If autoit was a suprise in a box, the box would be see through to the point where you're not even sure there's a box around it.

If autoit was a Ford 351 Cleveland, only one piston would work.

If autoit was a hit man, he'd snitch on every client he's worked with.

If autoit was a zippo, the flame would come out the other end.

If autoit was one of those 9 L.E.D Metrix Flashlights, only one L.E.D would work at a time.

--optimistic--

If autoit was your neighbor, he would never borrow your stuff.

If autoit was a your room mate, you wouldn't have to worry about your fridge.

If autoit was statefarm, he would actually be there...

Edited September 24, 2011 by THAT1ANONYMOUSEDUDE