object classes: coding style

Get help with using AutoHotkey and its commands and hotkeys
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

object classes: coding style

13 May 2018, 12:01

- There are various debates about how to write classes. Personally, although this is not necessarily standard or nonstandard, I would advise two things:
- Use Allman style (not K&R/1TBS style). [Easier to read.]
- Functions should do most of the work, the class should just be a wrapper. [Easier to reuse/maintain.]

- Classes are essentially functions (methods/properties) + data (keys).
- Classes often have two layers of complexity: the 'functions' (methods/properties), and how they are arranged/organised.
- Even if every method were just a call to an external function, classes can get complicated quite easily. The structure can be difficult to manage, and can often be under review (i.e. being regularly reorganised). The structures of a class's ancestor and descendant classes, and their interrelationships, may also be under review. This is why I advocate separating classes into two: external functions that do most of the work, and the class as a wrapper, essentially as a clerical tool for organisation.
- Also, by having most of the core functionality as separate functions, it is easier to follow the logic of the class, and it is easier for other classes to make use of some or all of the core functionality, or indeed to just use the functions directly in scripts. Also, it is easier to copy an individual function to a quick script, versus having to copy a class and all of its ancestors, just to use one method.

- Generally speaking, I would recommend that every class should have function equivalents. Exceptions:
- A class that tries to act as a new type of object e.g. a case-sensitive/case-insensitive dictionary object. Or a class that is a slight variant of the built-in AutoHotkey object, that has less/more/slightly different functionality.
- A class that acts as a 'quick hack' e.g. that takes advantage of the fact that objects have a __Delete meta-function, so that a specific action occurs when you delete an object.

==================================================

- I thought that an object wrapper for the SplitPath command could be a good example to use to demonstrate object classes with different coding styles.
- I would be interested to see different people try to code this, using their preferred styles.
- I am looking for a 'FileGet' function to return an object that works as below:
[EDIT: People could also post other simple classes, or links to them.]

Code: Select all

oFile := FileGet(vPath)
MsgBox, % oFile.dir

MsgBox, % FileGet(vPath).dir

;optional, to demonstrate what a function equivalent would look like
MsgBox, % FileGetPart(vPath, "dir")

;the equivalent using existing functionality
SplitPath, vPath, vName, vDir, vExt, vNameNoExt, vDrive
MsgBox, % vDir
- Here I created an object class in my preferred style, versus 2 alternatives that I imagine might be how others on the forum would code it.

Code: Select all

;file get part (OOP version)
Loop 3
{
	vNum := (A_Index = 1) ? "" : A_Index
	vPath := A_AhkPath
	;vPath := A_ScriptFullPath
	oFile := MyFileGet%vNum%(vPath)
	MsgBox, % oFile.dir
	MsgBox, % MyFileGet(vPath).dir
	MsgBox, % Format("path: {}`r`nname: {}`r`ndir: {}`r`next: {}`r`nNameNoExt: {}`r`ndrive: {}", oFile.Path, oFile.Name, oFile.Dir, oFile.Ext, oFile.NameNoExt, oFile.Drive)
}
return

;==================================================

;my preferred approach:
;- Allman style (not K&R style)
;- class has a function equivalent
;- function does most of the work (class is a wrapper)

MyFileGet(vPath)
{
	return new MyFileClass(vPath)
}

class MyFileClass
{
	__New(vPath)
	{
		this.path := vPath
	}
	__Get(vKey)
	{
		if (vKey = "path")
			return
		return MyFileGetPart(this.path, vKey)
	}
}

MyFileGetPart(vPath, vPart)
{
	SplitPath, vPath, vName, vDir, vExt, vNameNoExt, vDrive
	if (vPart = "path") ;path
		return vPath
	else if (vPart = "name") ;name
		return vName
	else if (vPart = "dir") ;directory
		return vDir
	else if (vPart = "ext") ;extension
		return vExt
	else if (vPart = "NameNoExt") ;name no extension
		return vNameNoExt
	else if (vPart = "drive") ;drive
		return vDrive
}

;==================================================

;another approach:
;- K&R style (not Allman style)
;- class has no function equivalent
;- class's __Get meta-function does all of the work (no function)

MyFileGet2(vPath) {
	return new MyFileClass2(vPath)
}

class MyFileClass2 {
	__New(vPath) {
		this.path := vPath
	}
	__Get(vPart) {
		if (vPart = "path")
			return
		vPath := this.path

		SplitPath, vPath, vName, vDir, vExt, vNameNoExt, vDrive
		if (vPart = "path") ;path
			return vPath
		else if (vPart = "name") ;name
			return vName
		else if (vPart = "dir") ;directory
			return vDir
		else if (vPart = "ext") ;extension
			return vExt
		else if (vPart = "NameNoExt") ;name no extension
			return vNameNoExt
		else if (vPart = "drive") ;drive
			return vDrive
		return
	}
}

;==================================================

;another approach:
;- K&R style (not Allman style)
;- class has no function equivalent
;- class properties do all of the work (no function)

MyFileGet3(vPath) {
	return new MyFileClass3(vPath)
}

class MyFileClass3 {
	__New(vPath) {
		this.path := vPath
	}
	name[] {
		get {
			SplitPath, % this.path, vName, vDir, vExt, vNameNoExt, vDrive
			return vName
		}
	}
	dir[] {
		get {
			SplitPath, % this.path, vName, vDir, vExt, vNameNoExt, vDrive
			return vDir
		}
	}
	ext[] {
		get {
			SplitPath, % this.path, vName, vDir, vExt, vNameNoExt, vDrive
			return vExt
		}
	}
	NameNoExt[] {
		get {
			SplitPath, % this.path, vName, vDir, vExt, vNameNoExt, vDrive
			return vNameNoExt
		}
	}
	drive[] {
		get {
			SplitPath, % this.path, vName, vDir, vExt, vNameNoExt, vDrive
			return vDrive
		}
	}
}

;==================================================
Last edited by jeeswg on 20 May 2018, 17:00, edited 8 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
wolf_II
Posts: 2685
Joined: 08 Feb 2015, 20:55

Re: object classes: coding style

13 May 2018, 13:18

Code: Select all

#NoEnv
obj := new SplitPath(A_ScriptFullPath)
MsgBox, ("obj")



;===============================================================================
class SplitPath { ; class wrapper for the SplitPath command
;===============================================================================

    __New(Path) {
        SplitPath, Path, Name, Dir, Ext, NameNoExt, Drive
        this.Name       := Name
        this.Dir        := Dir
        this.Ext        := Ext
        this.NameNoExt  := NameNoExt
        this.Drive      := Drive
    }
}
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

13 May 2018, 13:36

- Thanks wolf_II. I was interested in coding styles rather than the simplest possible SplitPath alternative per se.
- Although, I had meant to post 'simple' versions where you hardcode the values in the object, for demonstration purposes. Here are some examples:

Code: Select all

;SplitPath alternative: return an array

vPath := A_ScriptFullPath

oFile := MyFileGetSimple(vPath)
MsgBox, % oFile.dir

oFile := new MyFileClassSimple(vPath)
MsgBox, % oFile.dir
return

;==================================================

MyFileGetSimple(vPath)
{
	SplitPath, vPath, vName, vDir, vExt, vNameNoExt, vDrive
	return {path:vPath, name:vName, dir:vDir, ext:vExt, NameNoExt:vNameNoExt, drive:vDrive}
}

class MyFileClassSimple
{
	__New(vPath)
	{
		SplitPath, vPath, vName, vDir, vExt, vNameNoExt, vDrive
		this.path := vPath
		this.name := vName
		this.dir := vDir
		this.ext := vExt
		this.NameNoExt := vNameNoExt
		this.drive := vDrive
	}
}

;==================================================
- Also, I had in mind adding further functionality to the classes/functions:
file get part (SplitPath alternative/short-form/long-form/correct case) - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=6&t=47709
- And potentially a class that could act as a wrapper for every FileXXX command/function (with the possible exception of the FileOpen function).
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

15 May 2018, 08:54

You don't understand OOP.
You need to learn OOP before attempting a tutorial like this.
I honestly don't know if a single tip you have given here is correct.
I know that
- Use Allman style (not K&R/1TBS style). [Easier to read.]
This is just personal preference not a valid point for good code
- Every class should have a function equivalent. [Easier to reuse.]
This is simply not true. In fact if your classes have a function equivalent you are using them wrong. It's a good indicator for things you shouldn't do.
- Functions should do most of the work, the class should just be a wrapper. [Easier to maintain.]
I think this just shows that you still think in functions instead of objects when approaching classes.

What you provided here is an instruction to use a class to represent a data structure which is the result of a function.
Objects should always provide an interface for changing their own data - and by that I dont mean just changing the path by providing a new string - that would just be the result of a new call to your function.
I will provide an example of what I mean later on.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

15 May 2018, 09:07

- @nnnik: (You talk as if there is no debate re. OOP, there is a wide and heated debate re. OOP, you might say that no two people view OOP in the same way.)
- I'm writing a tutorial that explains how aspects of a class *work*, so that you can create a class, rather than how to write grand structures of interconnected classes. I will need at least one or two examples of complete classes to explain how they work.
- I am not concerned to debate how 'normal' or 'abnormal' your particular style of coding is. However, if you and others provide examples of your style, I can make reference to them in the tutorial. And if you can provide evidence (links) as to what the 'normal' style is, I can add those links to my tutorial. (I intend to present a class written different styles, but only if I have concrete examples from other people, so I very much welcome any contributions here.)
- If you disagree with anything I plan to write, you can write your own tutorial that overlaps with mine, I have no problem with that.
- (Even if I agree with anything that you say, I need evidence, especially for a *tutorial*. I didn't claim that anything I did was the de facto standard, and I gave arguments as to why I do what I do. And I *tried* to present a class in the style that I would imagine you would suggest, ready for you to amend the example. So far you have made points re. style without evidence or arguments.)
- I have added qualifications to the point in the OP that: 'Every class should have a function equivalent'.
- [EDIT:] You said you would provide an example later on, that's excellent, thanks.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

15 May 2018, 10:36

There are de facto standards for OOP mentioned in the SOLID guidelines. Also OOP stands for Object Oriented Programming - you orient yourself along functions and derive classes and objects from there. This can be a lot but not Object Oriented Programming.
I think for you using classes makes no more sense then using functions. However functions and classes are fundamentally conceptionaly different. Yet your coding style doesn't reflect that at all.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

15 May 2018, 21:17

- This thread originally had two aims:
(1) Get examples of simple classes, so that in my object class tutorial, I can demonstrate classes using standard (if such a thing exists) syntax.
(2) See how people reacted to my proposals for writing simpler classes.

- You question how relevant my proposals are to OOP/classes in AutoHotkey.
- I have suggested that people use Allman style, this would affect 100% of classes.
- I have suggested that people think in terms of functions, and think of classes as syntax sugar, a wrapper around those functions, this would affect 99%(?) of classes.
- Are there any classes written in AutoHotkey that would not benefit from both of these proposals? (Apart from the exceptions mentioned in the OP.)
- If you can find any exceptions, that would be most interesting.

- Some problems if people proceed counter to my advice:
- The more levels of indentation, the less clear the code is. Separating things as functions helps reduce the levels of indentation.
- I've seen methods, where everything is split up into tiny bits of code, it makes it hard to follow the logic of the class.
- I've seen libraries for individual GUI control types, that could be more easily generalised to handle multiple control types, if the major functionality was moved out to functions, rather than kept inside each method. Functions to do the real work, methods for organisational purposes.
- I've seen libraries for individual GUI control types, where I would like the code for one particular method as a stand-alone function for use in a quick script. It can be taxing to unravel the method into a function.
- Often I don't like the way a class is implemented, and if everything had just been written as functions with a class as a wrapper, the code would be more useful either as stand-alone functions, or as a class that I could quickly whip into shape.
- Arranging/organising even a small class can be quite complex, so if things are moved out to functions, it greatly helps to comprehend the overall structure of the class without any superfluous details obscuring the structure.
- Dealing with other people's classes in AutoHotkey has wasted more of my time than *anything* else.

- I am concerned that some people are too 'wedded' to classes, they see every programming problem as an OOP problem. From reading around it seems that the use and misuse of OOP is one of the major problems in the industry, possibly even the biggest problem, and that people are falling out of love with OOP.
- I am also concerned that some people code in a certain way for the wrong reasons. They try to stick exactly to a particular paradigm that they read in a course reader, but will never use any common sense or think for themselves. Thus you get unfathomable or bloated classes/class hierarchies. As a generalisation, such people change their OOP paradigms every 5 years, and are completely certain each time that they have the *right* paradigms.
- I am further concerned that people are imposing a view of both when and how to use classes. I see people being a bit pushy and overzealous with their OOP suggestions, such-and-such *must* be done. This is something that I tend not to see for other areas of programming.
- I also see comments implying that the knowledge of OOP experts ('experts'?) *must* be trusted.
- Thus I see questionable and potentially counterproductive advice being given out, that tells people erroneously(?) when and how they should use classes.

- Here are two examples where using classes (or using classes in a particular way) may or may not be the best way forward.
Code cleanup - PowerPoint COM - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=48893
[v1] Bug or limitation in associative arrays? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=46249
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

16 May 2018, 02:49

You are not affected by all of those views since you never learned OOP - you are essentially rejecting something you never learned out of reccomendation by somebody else.
Not ever problem is an OOP problem, but most problemss I tackle are. Also every problem is mostly a mixed problem so its fine to have functions sometimes.
Also whenever you read something like that OOP is the industries biggest problem remember that there are people on this planet tht try to find likely reasons as to why the earth is flat and why the national agencies are lying to us.

Also you need to know that OOP is a response towards the biggest problem in the industry and that is procedural programming ( using functions ).
This is backed by many facts: e.g. https://en.wikipedia.org/wiki/Software_crisis
- You question how relevant my proposals are to OOP/classes in AutoHotkey.
- I have suggested that people use Allman style, this would affect 100% of classes.
One again just personal preference.
- I have suggested that people think in terms of functions, and think of classes as syntax sugar, a wrapper around those functions, this would affect 99%(?) of classes.
- Are there any classes written in AutoHotkey that would not benefit from both of these proposals? (Apart from the exceptions mentioned in the OP.)
- If you can find any exceptions, that would be most interesting.
I didn't question how relevant things are I wanted to point out how irrelevant your suggestions are.
Your proposals are idiotic to me and it makes me face palm a lot. I have explicitly stated that OOP is the opposite of treating every class as a function. You seem to ignore this fact.
- The more levels of indentation, the less clear the code is. Separating things as functions helps reduce the levels of indentation.
Thats just personal preference - I prefer the opposite in fact.
- I've seen methods, where everything is split up into tiny bits of code, it makes it hard to follow the logic of the class.
One again personal preference
- I've seen libraries for individual GUI control types, that could be more easily generalised to handle multiple control types, if the major functionality was moved out to functions, rather than kept inside each method. Functions to do the real work, methods for organisational purposes.
You provide no reasoning why you would do this.
- I've seen libraries for individual GUI control types, where I would like the code for one particular method as a stand-alone function for use in a quick script. It can be taxing to unravel the method into a function.
Use the entire library?
- Often I don't like the way a class is implemented, and if everything had just been written as functions with a class as a wrapper, the code would be more useful either as stand-alone functions, or as a class that I could quickly whip into shape.
Thats just you prefering functions.
- Arranging/organising even a small class can be quite complex, so if things are moved out to functions, it greatly helps to comprehend the overall structure of the class without any superfluous details obscuring the structure.
Seem to me that you are not using a proper editor - I reccomend AHK Studio
- Dealing with other people's classes in AutoHotkey has wasted more of my time than *anything* else.
Normally those classes are documented and you dont even look into the source anyore. I dont know why you do this but you cannot complain when you waste time by always doing things that OOP was made against.
- I am concerned that some people are too 'wedded' to classes, they see every programming problem as an OOP problem. From reading around it seems that the use and misuse of OOP is one of the major problems in the industry, possibly even the biggest problem, and that people are falling out of love with OOP.
Dont be concerned about that you cannot even write OOP. Also this has always been a thing thats happening. There will always be so many rebellious people.
From what I see OOP still remains the sole winner. What I do agree with is that some people are taking OOP way too far and make everything ready for unit testing.
- I am also concerned that some people code in a certain way for the wrong reasons. They try to stick exactly to a particular paradigm that they read in a course reader, but will never use any common sense or think for themselves. Thus you get unfathomable or bloated classes/class hierarchies. As a generalisation, such people change their OOP paradigms every 5 years, and are completely certain each time that they have the *right* paradigms.
I am concerned that a specific somebody sticks to code in a certain way for the wrong reasons. He just tries to stick with the same coding style that he learned by teaching himself without ever consulting any form of authority ( like the literal institution for creating knowledge: university ), but he will never accept anything anybody else says and rather find some reasons why not learning it is the right decision online and he is completely certain that he has the right paradigms every time.
- I am further concerned that people are imposing a view of both when and how to use classes. I see people being a bit pushy and overzealous with their OOP suggestions, such-and-such *must* be done. This is something that I tend not to see for other areas of programming.
Classes only make sense in a specific fashion. Using it in your fashion only seems like extra work over using functions to me.
Also you state your style suggestions as facts that are probably right for every style out there and after you have been completely disproven and someone pointed out that the prevailing style cannot use your suggestions, you even ask if there are any rare exceptions. You are the one trying to force your style on other people right now :P And I'm trying to prevent that since the industry standard and the prevailing style for any kind of software project is a different style.
- I also see comments implying that the knowledge of OOP experts ('experts'?) *must* be trusted.
Let me guess - Stackoverflow? Stackoverflow is often taking OOP too far in my opinion and they are opinion nazis.
- Thus I see questionable and potentially counterproductive advice being given out, that tells people erroneously(?) when and how they should use classes.
That happens sometimes. But a tutorial using the style you mentioned above will keep people from harnessing the full power of classes and potentially might keep them from going to more advanced AutoHotkey use and keep them from learning something thats valueable for getting a job or learning other languages.
- Here are two examples where using classes (or using classes in a particular way) may or may not be the best way forward.
Code cleanup - PowerPoint COM - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=48893
I havent read through his code but the topic seems to be an OOP problem.
[v1] Bug or limitation in associative arrays? - AutoHotkey Community
https://autohotkey.com/boards/viewtopic.php?f=5&t=46249
As I posted in the topic I know more or less what it is about.

You need to understand that OOP is not a thing you can plug right in to an existing script but rather a design paradigm that has to be there right from the start in order to make it work.
So these are nice examples of scripts that are already ruined because they didn't use objects from the start.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

16 May 2018, 12:10

- @nnnik: Do you agree with these statements?
- The claims of OOP are a little bit overstated.
- OOP can get messy quickly.
- Dealing with someone else's OOP can be a nightmare.
- Some of the best people in the industry are somewhat/very sceptical about OOP.

- It is possible to argue that if everybody did OOP 'correctly', there wouldn't be any problems. However, it might be wiser to measure a paradigm like this: when people do it 'incorrectly', how bad are the consequences likely to be. [Judge a paradigm by how badly it can go wrong when somebody that isn't you uses it (and you have to fix it).]
- While it's possible to say that if someone knew more OOP they'd be less critical of it, sometimes the opposite is the case.

- I think that there are 2 fundamental problems with OOP: the approach and the culture.
- The approach says that the bigger the problem, the more OOP you need. (Programmers often end up rewriting the entire system from scratch multiple times.) Whereas I would say that the bigger the problem, the more you need to stick to simple principles.
- The culture appears to create a 'class' of proponents who often attack opponents in an uncouth way. Criticisms of OOP can either help strengthen OOP, or they can be defeated via good arguments.

- Re.
You are not affected by all of those views since you never learned OOP - you are essentially rejecting something you never learned out of recommendation by somebody else.
- Or contrariwise: you are limited by the finite number of OOP issues that you have encountered, and for everything else, you defend things that you don't use.
- I don't reject OOP entirely. Other people's criticisms tie in with my experiences. The biggest problem that I have faced when using AutoHotkey, is OOP, other people's use of OOP.
- Btw what in the 'software crisis' Wikipedia article supports your point?

- Re.
That happens sometimes. But a tutorial using the style you mentioned above will keep people from harnessing the full power of classes and potentially might keep them from going to more advanced AutoHotkey use and keep them from learning something that's valuable for getting a job or learning other languages.
- Advanced techniques need an advanced tutorial.
- Fundamentally all I have said is that it's a good idea to take code out of methods, and put it into separate functions. [Or to write functions first, and then write the classes as wrappers.]

- Perhaps if you wrote classes in a more straightforward manner, you wouldn't have such a need for this:
The very powerful exception function - AutoHotkey Community
https://autohotkey.com/boards/viewtopic ... 74&t=48740

- Re.
OOP is not a thing you can plug right in to an existing script but rather a design paradigm that has to be there right from the start in order to make it work.
So these are nice examples of scripts that are already ruined because they didn't use objects from the start.
- These are exactly the sorts of things that critics of OOP say.

- Btw what would you say is industry standard, Allman style or K&R style?
- Btw where is the OOP industry standard located? Which website?

- I think that you would benefit from having (or appearing to have) a more nuanced view of the pros and cons of OOP. I.e. it's good to show that you have introspected and aren't simply an ideologue.
- I don't know who you've been talking to, but there is a widespread general malaise about OOP. The solution might be to use different forms of OOP, or to use something outside of OOP, or a mixture, I don't really mind. I have solutions that work for me, 'OOP Lite', outlined in the OP.
- If you are such an expert on OOP, you will have encountered some OOP ideas that you disagree with. So you are, to an extent, a critic of OOP.
- A lot of people become sceptical about aspects of OOP, after a naive and cheerful start. It helps to have considered alternative approaches and to have been evaluating OOP sceptically from the earliest possible moment.

==================================================

RESPONSES TO QUOTES
OOP is a response towards the biggest problem in the industry
- An attempt to fix a problem is not necessarily a successful attempt to fix a problem.
stated that OOP is
- I'm using 'OOP' to refer to anything class-related. Please provide a definition if you wish to make a distinction. See also: Wikipedia's definition.
I prefer the opposite
- I'm surprised that you prefer more levels of indentation.
One again personal preference
- Splitting up what is effectively one function into multiple small methods makes code harder to follow. It's hard to argue against this.
You provide no reasoning why you would do this.
- AutoHotkey v2 itself uses one object type for multiple GUI controls.
Use the entire library?
- That's exactly what I don't want to do when I want to use one function in a quick script.
- Furthermore, sometimes you *can't* get the class to in effect act like a function, without major edits to the class.
- Sometimes you only want a bit of functionality e.g. a few lines, extricating even that can be difficult in some classes.
you cannot complain when you waste time by always doing things that OOP was made against.
- What? Doing things like understanding and amending the code.
From what I see OOP still remains the sole winner. What I do agree with is that some people are taking OOP way too far and make everything ready for unit testing.
- Interesting point. I feel that my approach doesn't intrinsically conflict with OOP principles. Also, I haven't necessarily decided that abolishing OOP is the best approach. However, it is quite possible that I would advocate using the very minimum of OOP in any given situation.
I am concerned that a specific somebody sticks to code in a certain way for the wrong reasons. He just tries to stick with the same coding style that he learned by teaching himself without ever consulting any form of authority ( like the literal institution for creating knowledge: university ), but he will never accept anything anybody else says and rather find some reasons why not learning it is the right decision online and he is completely certain that he has the right paradigms every time.
- I started off looking at other people's classes, considered things I liked and disliked, and came up with the ideas in the OP.
- I've considered/read all sorts of arguments regarding OOP, my general view is that OOP is OK, but the less OOP the better, for more readable/maintainable code, and, that simpler is generally better.
completely disproven
- ?
Stackoverflow?
- No, it was actually this forum, but not said in such a direct way.

- Basically, I value your input on OOP. I feel that you might be in a good position to do a critique of OOP, different debates, and where you stand on them, your likes and dislikes.
- Quite often you refer to things as 'standard', I really would appreciate it whenever you can to provide links. I welcome any information text/videos that would challenge my views.
- Being too anti or too *pro* something might lead to some future facepalming on your part! It's always best to take the line of moderation. I will be posting a collection of powerful material critiquing OOP.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

16 May 2018, 13:43

The most commonly used language is Java.
Followed by C and afterwards by many object oriented languages.
Java is pretty much the industries standard:
https://www.tiobe.com/tiobe-index//
If you want to learn OOP learn Java. Even an idiot can write proper OOP
- The claims of OOP are a little bit overstated.
Practical effect speaks best and while people often tend to excegerate the effect of OOP it is right that the industry became more successful, wide spread, advanced and efficient after switching to OOP.
- OOP can get messy quickly.
functions and labels can get quickly messy too - if you do not design things it will get messy. OOP is the opposite of going head -> screen, at least when you are a beginner.
- Dealing with someone else's OOP can be a nightmare.
not more than dealing with someone elses functions
- Some of the best people in the industry are somewhat/very sceptical about OOP.
But whether they think that procedural programming is better is another question. OOP does have it's issues, but I think it's a step in the right direction.
- It is possible to argue that if everybody did OOP 'correctly', there wouldn't be any problems. However, it might be wiser to measure a paradigm like this: when people do it 'incorrectly', how bad are the consequences likely to be. [Judge a paradigm by how badly it can go wrong when somebody that isn't you uses it (and you have to fix it).]
No your entirely wrong on that. Measuring a pardigm is only possible within a context. You cannot judge something if you have no relation towards it. If we look at it from an industries perspective it's positive due to aforementioned effects.
Also procedural stuff can go just as wrong. Just imagine using an eval function which uses global scope to save data about variables that were input using a string. Just plain horrible ( The type of horror that crawls down under your skin )
Recommends AHK Studio
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

16 May 2018, 13:45

To conclude this discussion and to close it - every larger piece of software that you use uses OOP including this forum.
I dont know where you get your sources from but if you want to join team "flatearth" do it by yourself outside of this forum.

Also your definition of OOP is way off. I have written you a definition several times but you seem to forget it all the time.
Recommends AHK Studio
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

16 May 2018, 14:21

- Your definition of OOP appeared to shift depending on your line of argumentation. You're welcome to settle on a definition now, hopefully one that corresponds with the Wikipedia article.
- One of the problems with OOP devotees, other than sometimes what they argue, is how they argue. Maybe sometimes people do things in jest, but I think it's important that people feel able to talk about topics like OOP in an open and friendly way.
- Btw how much do you like OOP? Do you think that OOP should get the Nobel Peace Prize?

- As I said before, if people include class examples, I can use them in any tutorials. You mentioned an example earlier that I would be happy to take a look at.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Helgef
Posts: 3890
Joined: 17 Jul 2016, 01:02
Contact:

Re: object classes: coding style

16 May 2018, 15:00

every larger piece of software that you use uses OOP
every function we write in ahk causes an instance of some Func class :D
- Btw how much do you like OOP? Do you think that OOP should get the Nobel Peace Prize?
:lol:

Cheers.
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

16 May 2018, 15:21

You do not know the definition of the word OOP - why am I talking to you about this topic?
You cannot use OOP and have no experience in writing in any language other than AHK.
Of course OOP is bad if you look at a language which is not meant for OOP.
You have not tackled any complex programming problems.
You are simply put not a programmer.
You cannot discuss advanced knowledge without providing prove of having basic knowledge.
Why am I talking to you?
- Btw how much do you like OOP? Do you think that OOP should get the Nobel Peace Prize?
No ffs but it's the closest we get to Jaques Deridas philosophical definition of system theory.
Recommends AHK Studio
User avatar
nnnik
Posts: 4242
Joined: 30 Sep 2013, 01:01
Location: Germany

Re: object classes: coding style

16 May 2018, 15:43

You have not seen the power of frameworks like Django in Pyhon or Laravel in PHP...
Recommends AHK Studio
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

21 May 2018, 16:10

@nnnik: Are there any programming languages or paradigms/books etc that closely align with your preferred vision of OOP?
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

23 May 2018, 03:03

- Look nnnik, if I take something seriously, you should take it seriously too.
- At the higher level: OOP projects start off with an elegant structure which then becomes a Rube Goldberg machine or is replaced entirely (multiple times).
- At the lower level (including AHK): simple projects become bloated and less readable by using OOP unnecessarily.
- This is the problem of the OOP philosophy.
- But actually, those are the symptoms, not the causes.
- nnnik, this is what your problem is:
Handmade Hero | Getting rid of the OOP mindset - YouTube
https://www.youtube.com/watch?v=GKYCA3UsmrU#t=112
[1:52 to 2:41]
- It helps to explain why CS graduates are often 'worse' programmers than self-taught programmers.
- If the point isn't made clear to you by the video, read the comments for more information.

- [EDIT:] This post may look more negative than I intended.
- I use OOP, and to an extent I like OOP.
- Since viewing other people's scripts, and facing challenging problems within my own scripts, I've tried to find a middle way where I can use OOP but avoid the common problems.
- Essentially it involves using as little OOP as possible, moving out complex code to functions, avoiding complex hierarchies, and viewing OOP in a more clerical way. By keeping the classes simple, and focused on structure, and not functionality, it becomes easier to restructure the class hierarchies at a later date.
- To say vaguely that by doing this, 'it isn't OOP any more', that's neither useful nor true.
- I have found that people who want to, or have to, use OOP, while avoiding the common problems, have ended up coming to similar conclusions.
- If someone wanted to really be helpful, they would go through various large-scale coding problems, and talk about the least-worst OOP/mixed solutions that they came up with, in simple terms. A fireside chat rather than a mammoth tome. Reading Design Patterns by the Gang of Four is no substitute for a more practical sensible comprehensive reflection on the issue.
- OOP directly or indirectly is a greater source of problems in IT than perhaps any other paradigm. It doesn't make any sense for OOP advocates to attack OOP critics indiscriminately. OOP advocates made the mess, they need to fix it.
Last edited by jeeswg on 23 May 2018, 17:37, edited 2 times in total.
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA
Helgef
Posts: 3890
Joined: 17 Jul 2016, 01:02
Contact:

Re: object classes: coding style

23 May 2018, 03:42

I find the video interesting for one reason, he said oop, like it was a word, not a three letter abbreviation, disregarding that, what a waste of time and space :facepalm: .
User avatar
jeeswg
Posts: 6642
Joined: 19 Dec 2016, 01:58
Location: UK

Re: object classes: coding style

23 May 2018, 13:32

- @Helgef: He explains the straightforward mindset and the OOP mindset.
Handmade Hero | Getting rid of the OOP mindset - YouTube
https://www.youtube.com/watch?v=GKYCA3UsmrU#t=1m52
[1:52 to 2:41]
I want the computer to put a red dot here, how do I do that?
versus:
Oh do I need to abstract the concept of a screen, and red, should red be an object that, oh what is this, is a pixel an object or is it a group of objects, is there a container, do I have to ask a factory to get me a color and that color is red.
- I've seen some programmers that I respect, that, because of their OOP instruction, take simple things to ludicrous levels of complexity.
- Unfortunately such people could argue, 'yes it's bad code, but it's commonplace at universities', to which I might say: fair enough, but that isn't a very productive attitude.
- If you read through the comments, the moral of the story is: Java shouldn't be your first language, learn to code *before* you do a CS degree.
- The problem with some OOP advocates is that they blame everybody but themselves: 'OOP has no problems, only critics'.
- If most people use something badly, there's either a problem with the thing itself, or a problem with the culture that tells them how to use it.
- OOP advocates are responsible for the culture, if a large proportion of people, the majority even, are using OOP 'incorrectly', the focus of the criticism has to be on the centres of power, and not on the individual programmers.
- Btw these videos are interesting:
Object-Oriented Programming is Bad - YouTube
https://www.youtube.com/watch?v=QM1iUe6IofM
Object-Oriented Programming is Embarrassing: 4 Short Examples - YouTube
https://www.youtube.com/watch?v=IRTfhkiAqPw

- [EDIT:] In this video, Alan Kay, who coined the term 'OOP', pronounces OOP as 'oop' also, so Casey Muratori is in good company.
Alan Kay at OOPSLA 1997 - The computer revolution hasnt happened yet - YouTube
https://www.youtube.com/watch?v=oKg1hTOQXoY#t=9m2
- In the same video at 10:34, Alan Kay states the classic phrase: 'Actually I made up the term 'object-oriented', and I can tell you I did not have C++ in mind.'
homepage | tutorials | wish list | fun threads | donate
WARNING: copy your posts/messages before hitting Submit as you may lose them due to CAPTCHA

Return to “Ask For Help”

Who is online

Users browsing this forum: Bing [Bot], effel, flyingDman, FrankFromPdaSoft, Getfree, Godvicien, Google [Bot], ndiaz, Odlanir and 198 guests