Talk:Metaobject

message: Do Java's java.lang.reflect.* classes implement a limited, if any, form of a MOP? Or is intercessive reflection an essential requirement? --Wouter Lievens 13:08, 1 May 2005 (UTC)
replies: text: I would say that, no, the java.lang.reflect does not implement a mop in any sense. It is purely a way of performing reflection. A mop, would, for example, allow a programmer to alter the way inheritance is implemented, or alter the way dynamic dispatch works. Providing a standard means for (meta-)programmers to change the garbage collection algorithm of a java implementation is another example of what a mop could do. --Andrew Eisenberg 23:08, 5 May 2005 (UTC)
thread_title: MOPs in Java?

message: It is real nice that those references are included at the bottom. But please note that it is better to use .
When I altered the article I did the following:
* More headlines, improving readability
* Added the  tag, as it should be
* Kept the original references, to help reminding.
I must say that the article is more about Metaobject protocol than metaobject.
And it is better to get references from other places than wikipedia.
Daanie92 (talk) 00:50, 4 August 2009 (UTC)
thread_title:  References needed 

message: Currently in the sub section: Run Time and Compile Time it says the following: "MOPs may be run-time or compile-time. The metaobjects of runtime MOPs exist while a program is running, or executing. On the other hand, the metaobjects of compile-time MOPs exist only while a program is compiled. They may alter or extend the compiling process, but do not exist when the program is running...A good example of a compile-time MOP is OpenC++." I don't understand this. How can you have a meta-object protocol at compile time? The software isn't executing at compile time so I don't see how that makes sense. And the example of Open C++ doesn't seem convincing to me. That seems like a tool for doing ANALYSIS of C++ code so it seems to me that such analysis is run time not compile time. I don't know much about C++ though, my experience with OO is more in CLOS, Smalltalk, and Java so I don't want to change it without doing more research or getting input from others. MadScientistX11 (talk) 16:48, 26 December 2013 (UTC)
replies: text: I removed the disputed tag I added a while ago. I found this paper: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.7049 that makes it clear there are tools that work at compile time and use a meta object protocol in C++. MadScientistX11 (talk) 17:48, 26 December 2013 (UTC)
thread_title:  Run Time and Compile Time? 

message: The whole article sounds more or less confused and has numerous issues.
* the first paragraph is claiming things, for which not an exact source is given. 
* the is also not 'a metaobject', but there many different kinds of metaobjects
* MOP paragraph
** does not make clear what the meta-level is and how it differs from the object-level
** violate good standard: WTF?
** the use cases for MOPs quite different from what is mentioned here. One use case is especially to be able to provide different object-system semantics in one framework. Another one is to provide extension interfaces to an object system.
* Runtime / Compile time
** interpreted environments like CLOS and Smalltalk. That's also confused. CLOS environments are usually compiled, but still provide a runtime MOP
** Semantic web: the mention here of the Semantic web is arbitrary and has little to do with MOPs. The linked article just compares different technologies.
* Usage
** the multiple inheritance issue has nothing to do with the MOP. A important difference between Smalltalk and CLOS is that Smalltalk only provided implicit metaclasses. CLOS made them explicit. The research literature describes this in detail. 
** CASE, IDE, etc. no examples or sources are given.
** MOPs are also not an implementation way for Aspect-oriented languages. Actually AOP is an evolution and provides some similar services, but with a different approach. That people like Gregor Kiczales moved their research topic to AOP is historically and long ago. It's not clear what they 'advocate' now.
* See also
** random collect of topics, without explanation why they are listed
Joswig (talk) 22:51, 1 January 2014 (UTC)
thread_title:  This article needs a major improvements 

message: "Magic methods" redirects here (from e.g. Python (programming language)), but not mentioned in the article. 
What are "Magic methods"? Madacs (talk) 23:55, 14 November 2014 (UTC)
thread_title:  Magic methods? 

message: Hello fellow Wikipedians,
I have just modified one external link on Metaobject. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
*Added archive https://web.archive.org/web/20140107000613/http://www.metaware.fr/images/pdf/1_Metaware_The_Origin%20of_Refine_Whitepaper.pdf to http://www.metaware.fr/images/pdf/1_Metaware_The_Origin%20of_Refine_Whitepaper.pdf
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 17:23, 26 January 2018 (UTC)
thread_title:  External links modified (January 2018) 

message: The weirdly polemical section starting “Metaobject protocol is contrary to Bertrand Meyer's open/closed principle, which holds that software object systems should be open for extension but closed for modification” makes the fundamental error of conflating policy with mechanism. A doctrinal Meyersian might well insist that a ‘good’ new programming language design have strict access controls on the metaobject protocol in order to permit (or require) enforcement of closure for modification, but this is completely unrelated to the question of the implementation techniques required to build and bring up a true everything-is-an-object environment, which necessarily (or nearly so) require the existence of a metaobject protocol in the bootstrap. The key of a metaobject protocol is, after all, the means by which a true class Class is provided, and everything else (including important things unmentioned in this article like the ability to introduce new underlying code and data representations from within the language) descends from that. Weird mechanisms like update-instance-for-changed-class have more to do with handling the realities of interactive and long-lived nature of LISP (Smalltalk, etc.) sessions than the they do with a MOP in itself.
I'm also boggled by the final paragraph. AOP is a very different philosophical beast, apparently inspired more by macro processors and LISP debugging advice mechanisms than a mathematical need for Class : Class, and focusing on intervention on existing code paths rather than substituting for them from the start. And Java (with or without aspects) is very much not a  reflection of any particular philosophy, but (my turn to be polemical) an attempt to build a single-dispatch LISP with less completely advisory types and (for reasons that will never make any sense to me) C syntax. But in any case, why shouldn't people take their careers wherever they want? How does this invalidate their earlier work? 2600:1700:38D4:604F:E167:43A7:2E3E:982A (talk) 21:14, 19 April 2023 (UTC)
thread_title:  Confusion of policy and mechanism, here