Talk:Metaobject

MOPs in Java?

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)

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)

Aspect orientation

The lack of a meta-object protocol in languages such as Java is one of the motives for the development of aspect-oriented programming.

I disagree with this comment from the main page. AOP came about as a way to modularize crosscutting concerns, it has nothing to do with not having a mop in Java. It is true that a mop is one way to implement an aop language. It's also true that the many people who worked on early mop implementations are now working on early aop implementations. A better way of saying this would be:

A metaobject protocol is one way to implement aspect-oriented programming languages. Many of the early founders of MOPs, including Gregor Kiczales have since moved on to be the primary advocates for aspect-oriented programming.

References needed

It is real nice that those references are included at the bottom. But please note that it is better to use <ref></ref>.

When I altered the article I did the following:

• More headlines, improving readability
• Added the <references/> 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)

Run Time and Compile Time?

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)

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)

This article needs a major improvements

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)

Responses to: This article needs a major improvements

This is in response to the comments above. My replies are in Italics.

• the first paragraph is claiming things, for which not an exact source is given.

This is an accepted practice on Wiki articles. You can say things in the intro that are explained with references in the main article and as long as they are referenced in the article that is considered OK.

• the is also not 'a metaobject', but there many different kinds of metaobjects

I don't know what that means. There are of course different kinds of meta objects, what specifically are you talking about?

• MOP paragraph
  • does not make clear what the meta-level is and how it differs from the object-level

Do you have some example language that makes it clearer. It seems fairly clear to me, meta means an object that represents another object rather than a thing in the domain of the software.

• • violate good standard: WTF?

I thought this might ruffle some feathers when I wrote it. My point is that if you look at the Open_Closed_Principle of OO (see Bertrand Meyer's book OO Software Construction): "software entities (classes) should be open for extension, but closed for modification" I.e., if you re-use something you shouldn't even potentially be able to mess it up. You can't get less closed than mucking around with meta objects. Essentially using metaobjects is the ultimate goto, you can redefine the system, the control flow, data flow, class hierarchy, etc. in any way you want and completely disregarding any intentions other designers had about constraints on how the system should be maintained and evolved. That was the point. Also, the point was that because of this people don't usually use metaobjects casually. It's something that less experienced developers are cautioned not to use and that when you do use it on a project there needs to be some special reason (e.g. you are doing AI or a learning program or some kind of game where you need to create new types of things on the fly). It seemed to me kind of like the "2 + 2 = 4" kind of fact that no one who has real IT experience with OO systems would disagree with but if someone does then obviously that isn't the case.

• • 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.

I agree there is a lot more to MOPs than what is so far in this article.

• Runtime / Compile time
  • interpreted environments like CLOS and Smalltalk. That's also confused. CLOS environments are usually compiled, but still provide a runtime MOP

That is why it said "interpreted environments" rather than interpreted code. Perhaps talking about late binding vs. early binding would be more appropriate but I didn't want to get into that level of detail at this point.

• • 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.

The article specfically goes into the different object models between the semantic net and OO as it is currently practiced. E.g., look at section 3.3 A Comparison of OWL/RDF and Object-Oriented Languages. And I think that is a major issue, you either can't do or are usually strongly discouraged from doing meta-object things like redefining a class at run time in most environments (in my experience even in most CLOS and Smalltalk projects people stay away from it) but it's an integral part of the semantic web paradigm as that paper makes clear.

• 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.

I think it has a lot to do with the MOP. Whether or not your language supports multiple inheritance will impact what your MOP does. The obvious thing is whether the meta-object for class supports multiple inheritance. It will also have a big impact if you write meta-programs that for example generate code for methods. If you have multiple inheritance that code generation becomes a LOT more complex. I think that is a reasonable issue to bring up.

• • CASE, IDE, etc. no examples or sources are given.

I will add some. I added some examples from the Lisp world. I also found this: http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_VI.html I don't think that is good enough for a reference but it supports my point that even people in the Smalltalk community don't recommend indescriminate use of meta objects and think it can cause confusion and that a main use for the meta objects is in the environment itself, that article talks about using the meta object as a way to present different views of a class being defined.

• • 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.

I don't know much about Aspect-oriented and was just re-using what was in the older version of the article and just trying to clean up the refs and make the text flow and understandable English. If you have a suggested change please leave it here or of course feel free to edit yourself.

• See also
  • random collect of topics, without explanation why they are listed

I agree. When I do a major re-write (as I did on this article a while ago) I try not to just slash away at stuff in case someone objects. But I agree completely this article (and in fact surprisingly many computer science articles) has a laundry list of see also topics that aren't needed. I'll prune some.

--MadScientistX11 (talk) 19:40, 6 January 2014 (UTC)

This paragraph is confusing:

Metaobject protocols were also extensively used in software engineering applications. In virtually all commercial CASE, reengineering, and Integrated Development Environments there is some form of metaobject protocol to represent and manipulate the design artifacts.

1) I don't know what CASE and reengineering could refer to here.

2) Is IDE software really an example of this? Is it referring to the IDE representation of, for instance, a class in the source code? This doesn't seem like the sort of "metaobject" described in the article, since the class itself is not run by the IDE. 2620:0:1003:1215:7F69:8E4A:8EBA:8826 (talk) 14:37, 13 July 2022 (UTC)

Magic methods?

"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)

External links modified (January 2018)

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.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 17:23, 26 January 2018 (UTC)

Confusion of policy and mechanism, here

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)