<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
 <a href="http://en.wikipedia.org/wiki/Class_%28computer_programming%29" target="_blank">http://en.wikipedia.org/wiki/Class_%28computer_programming%29</a><br>
 "Classes are composed from structural and behavioral constituents."</blockquote><div><br></div><div>Of course, using such a definition, even Fortran IV code consisted of classes!</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
which is _exactly_ what gbuild does in the best way supportable in make.</blockquote><div><br></div><div>Best way supportable? It is not hard to imagine even more elaborate/elegant/complex way to write code using GNU Make functions/macrosthat would make possible actual OO concepts like inheritance and virtual functions<span></span>. Like not defining functions directly but through some meta function, and calling functions of some class through a meta-function that would handle looking up the method in a class inheritance hierarchy etc. No, I don't think that would be a good idea necessarily. But surely you are suffering from some kind of bias if you think the current situation is the best possible.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
GObject also uses this vocabulary in a non-OOP language and if it wouldnt, it<br>
would be even harder to grok the concepts. ;)</blockquote><div><br></div><div>C is a completely different language than Make macros. </div><div><br></div><div>--tml</div>