Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Object-oriented design patterns in C and kernel development

oshub.org

Post reply on HN
Print view View original

201–210 of 224 posts

Re: Object-oriented design patterns in C and kernel development

#201

Post by 1718627440 »

ryao wrote: post #193
1718627440 wrote: post #189

Earlier quoted context omitted.

Ok, we can name it a vtable if it's done by the language and a wtable if it is done by the programmer. I don't care about this distinction, the mechanism is the same, the effects are the same, the implemented theory (OOP) is the same. Heck event the emitted code is the same. I guess the vtable implementations in a C++ compiler are now called wtables.

It is not the same theory, since it is an ADT, not anything object oriented. Different theories can and do overlap. The emitted code is also not the same, since there is no implicit this pointer. You are the one who posted a definition you found and then claimed that it agreed with you, when it did not and now are reneging on your use of it. You do not understand this topic as well as you think you do and this is a s…

> You are the one who posted a definition you found and then claimed that it agreed with you

X is Y used in Z. Does that mean X is not Y when it is not used in Z? A knife is a sharp object used to cut meat. How do I call the thing to cut fish?

Yes, I see how you can parse the definition your way, I didn't thought about that before introducing it.

> since it is an ADT, not anything object oriented

Yes, they have large overlap. To my understanding, the difference is, that OOP has inheritance and an ADT can be provided by the big god object. The latter I would refrain to call OOP, although it can be argued it still is.

I think our real discussion here is, whether a function entry that doesn't take an argument of the object type precludes it being a vtable. To me it is as long as this function is supposed to be a method of a single object and not for all objects in general, i.e. a global function.

Re: Object-oriented design patterns in C and kernel development

#202

Post by 1718627440 »

ryao wrote: post #194
1718627440 wrote: post #190

Earlier quoted context omitted.

No the type of an object isn't known until runtime, so the compiler can't know it. Yes you know the type of the vtable, which means you know the supertype. This is true in all languages that don't use duck-typing. No you don't know the assigned values of entries in the vtable, which means you don't know the type of the object. > Read my previous comment for the bug No this is not a bug. The entire point of inheritanc…

I never said that the type was known before runtime in OO. Your not a bug comment sounds awfully like an all bugs are features. Implementing static member functions this way would cause undefined behavior, which is a bug.

> Implementing static member functions this way would cause undefined behavior, which is a bug.

Yes. My point is, that it can't be a static member function, because it's overridden by subclasses.

Re: Object-oriented design patterns in C and kernel development

#203

Post by 1718627440 »

ryao wrote: post #195
1718627440 wrote: post #188

Earlier quoted context omitted.

That's a very good example. When I invoke object->Foobar() I want to invoke the appropriate method for this object, from whatever class that might be. This is exactly what's happening in the kernel here. When I actually intend to call the method from ClassA, I would either call something like object->base->Foobar() or ClassA->Foobar(object). Note how this is the very example that you are replying to: https://news.yco…

You don’t implement calls to static member functions by putting them into a vtable, which is one of many reasons why this is not a vtable. The proper way to implement static functions is through static dispatch.

> You don’t implement calls to static member functions by putting them into a vtable

Yes, you claimed it is like a static member function, I don't think it can be.

> The proper way to implement static functions is through static dispatch

Yes, but we are talking about dynamic dispatch here.

To quote your earlier comment:

> which is most unlike a vtable since static member functions are never in vtables

You conclude it isn't a vtable, I conclude, it's not a static member function, because it uses dynamic dispatch.

I don't think we actually disagree on how and when to use static and dynamic dispatch.

Re: Object-oriented design patterns in C and kernel development

#204

Post by 1718627440 »

ryao wrote: post #198
1718627440 wrote: post #192

Earlier quoted context omitted.

> The calling convention for C++ non-static member functions always includes a this pointer, even if the function does not use it. Yes. Since we are not in C++ we can choose to get rid of this useless pointer. > Removing it on member functions that do not use it would pose a problem if another class inherited from this class and overrode the function definition with one that did use it. That problem has nothing to do…

> Yes. Since we are not in C++ we can choose to get rid of this useless pointer. If you were trying to implement OOP in the kernel in C and implemented a vtable, you cannot get rid of the this pointer in vtable entries since a child class might want to use it in the overrode definition. It is one of the same reasons why you cannot remove it in C++. The entire point of a vtable is to enable inheritance. If OOP really…

This is one interpretation. The other is that the interface of check_flags() specifies, that any implementation of it is only allowed to differ on the type of the object and not any other property.

You already prescribe with the chosen arguments in the superclass on which things the child implementation can depend. Why not also do this with the first argument?

Re: Object-oriented design patterns in C and kernel development

#205

Post by ryao »

1718627440 wrote: post #201
ryao wrote: post #193

Earlier quoted context omitted.

It is not the same theory, since it is an ADT, not anything object oriented. Different theories can and do overlap. The emitted code is also not the same, since there is no implicit this pointer. You are the one who posted a definition you found and then claimed that it agreed with you, when it did not and now are reneging on your use of it. You do not understand this topic as well as you think you do and this is a s…

> You are the one who posted a definition you found and then claimed that it agreed with you X is Y used in Z. Does that mean X is not Y when it is not used in Z? A knife is a sharp object used to cut meat. How do I call the thing to cut fish? Yes, I see how you can parse the definition your way, I didn't thought about that before introducing it. > since it is an ADT, not anything object oriented Yes, they have large…

The point of a vtable is to implement virtual member functions that support inheritance and polymorphism without changing the base class implementations no matter what the child classes do. If you omit the this pointer, you cannot do inheritance that uses the this pointer in an override without changing the implementation of the parent to add the this pointer back, which would be like a tail wagging a dog. Thus, it is not a vtable. It is something similar, but different.

Re: Object-oriented design patterns in C and kernel development

#206

Post by ryao »

1718627440 wrote: post #202
ryao wrote: post #194

Earlier quoted context omitted.

I never said that the type was known before runtime in OO. Your not a bug comment sounds awfully like an all bugs are features. Implementing static member functions this way would cause undefined behavior, which is a bug.

> Implementing static member functions this way would cause undefined behavior, which is a bug. Yes. My point is, that it can't be a static member function, because it's overridden by subclasses.

It cannot be overridden by subclasses without risking undefined behavior because there is no this pointer for it to use.

Re: Object-oriented design patterns in C and kernel development

#207

Post by ryao »

1718627440 wrote: post #203
ryao wrote: post #195

Earlier quoted context omitted.

You don’t implement calls to static member functions by putting them into a vtable, which is one of many reasons why this is not a vtable. The proper way to implement static functions is through static dispatch.

> You don’t implement calls to static member functions by putting them into a vtable Yes, you claimed it is like a static member function, I don't think it can be. > The proper way to implement static functions is through static dispatch Yes, but we are talking about dynamic dispatch here. To quote your earlier comment: > which is most unlike a vtable since static member functions are never in vtables You conclude it…

If you leave out the this pointer, it is the equivalent of putting a function pointer to a global function (or a static member function) into the structure. This is not how OOP works.

Omitting the this pointer also breaks inheritance, since hypothetical child classes would not be able to override the definition while using the this pointer. Having to edit the parent class to be able to do that is not how OOP works.

This is not OOP nor is it intended to be.

Re: Object-oriented design patterns in C and kernel development

#208

Post by ryao »

1718627440 wrote: post #204
ryao wrote: post #198

Earlier quoted context omitted.

> Yes. Since we are not in C++ we can choose to get rid of this useless pointer. If you were trying to implement OOP in the kernel in C and implemented a vtable, you cannot get rid of the this pointer in vtable entries since a child class might want to use it in the overrode definition. It is one of the same reasons why you cannot remove it in C++. The entire point of a vtable is to enable inheritance. If OOP really…

This is one interpretation. The other is that the interface of check_flags() specifies, that any implementation of it is only allowed to differ on the type of the object and not any other property. You already prescribe with the chosen arguments in the superclass on which things the child implementation can depend. Why not also do this with the first argument?

You would typically put the this pointer into the first argument when doing OOP in C. You can put the this pointer in the last argument to have it work too. However, you cannot omit it entirely. That is something that is not OOP. It is an ADT.

Re: Object-oriented design patterns in C and kernel development

#209

Post by ryao »

1718627440 wrote: post #199
ryao wrote: post #186

Earlier quoted context omitted.

A stub is an empty implementation. An empty implementation is different from no implementation, where there is no code to execute. It is the difference between writing 0 and writing nothing.

If you care about this distinction, yes. However the LWN post describes how both can be used to implement the same behaviour, that their is no defined special implementation.

I have no idea what LWN post you mean. You can make stubs trap by doing a NULL function pointer dereference, but that does not make NULL function pointer dereferences the same as stubs in general.

Re: Object-oriented design patterns in C and kernel development

#210

Post by ryao »

1718627440 wrote: post #200
ryao wrote: post #185

Earlier quoted context omitted.

Data abstraction is a separate invention from OOP since it involves abstract data types. What is being used here is an abstract data type. It is not the pattern used in OOP languages and it is not OOP. It bears similarities and overlap with the vtables used to implement some OOP languages. It is like how thumbs bear similarities and overlap with index fingers, but the two are not the same.

To cite Wikipedia: > Object-oriented programming (OOP) is a programming paradigm based on the object – a software entity that encapsulates data and function(s). An OOP computer program consists of objects that interact with one another. A programming language that provides OOP features is classified as an OOP language [...] You don't disagree, that this kernel pattern is about data abstraction. You probably don't dis…

You can use similar logic to declare English to be an example of Chinese. They both have syllables. They both assemble syllables into words that convey meaning. They both use grammars to form relationships between those words. Thus, they must be the same. It is fallacious logic. Some similarities do not make things the same. Data abstraction is also its own topic that is able to stand independently from OOP. What the kernel does is data abstraction, not OOP. What you are seeing in the kernel are the abstract data types of data abstraction.
Post reply on HN