Short BOOPSI Overview - Revision history

Krashan: Link to Polish version.

2011-01-17T07:12:50Z

Link to Polish version.

Krashan at 10:52, 30 December 2010

2010-12-30T10:52:19Z

Krashan: /* Classes */ Style

2010-12-30T10:51:52Z

‎Classes: Style

AusPPC: minor readability fixes

2010-11-19T01:22:23Z

minor readability fixes

Krashan: /* Setting an Attribute */ Made a link working.

2010-11-17T10:09:49Z

‎Setting an Attribute: Made a link working.

Krashan: /* MUI Extensions to BOOPSI */ Do not use direct string literals for public MUI classes.

2010-11-17T10:00:20Z

‎MUI Extensions to BOOPSI: Do not use direct string literals for public MUI classes.

Krashan: Fixed small bug in a code.

2010-11-17T09:05:40Z

Fixed small bug in a code.

Krashan: /* MUI Extensions to BOOPSI */ Style.

2010-11-15T13:44:13Z

‎MUI Extensions to BOOPSI: Style.

Krashan: /* Classes */ Style.

2010-11-15T13:37:44Z

‎Classes: Style.

Krashan: /* MUI Extensions to BOOPSI */ Contents.

2010-11-15T13:33:07Z

‎MUI Extensions to BOOPSI: Contents.

← Older revision		Revision as of 07:12, 17 January 2011
Line 1:		Line 1:
	''Grzegorz Kraszewski''		''Grzegorz Kraszewski''
		+
		+
		+	----
		+	<small>This article in other languages: [[Rzut oka na BOOPSI\|Polish]]</small>
		+
	==Object Oriented Programming==		==Object Oriented Programming==

← Older revision		Revision as of 10:52, 30 December 2010
Line 20:		Line 20:

	Shared classes use the MorphOS shared library framework, in other words a shared BOOPSI class is just a kind of shared library. The class adds itself to the public list of classes, when it is opened from disk. As such, a BOOPSI shared class should be opened with ''OpenLibrary()'' before use ([[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing\|see details]]), especially as BOOPSI classes are usually not included into the list of libraries opened automatically. '''This is not the case for MUI classes''' however. MUI shared classes can be used without opening them. It is explained below, in the [[Short_BOOPSI_Overview#MUI_Extensions_to_BOOPSI\|MUI Extensions to BOOPSI]] section.		Shared classes use the MorphOS shared library framework, in other words a shared BOOPSI class is just a kind of shared library. The class adds itself to the public list of classes, when it is opened from disk. As such, a BOOPSI shared class should be opened with ''OpenLibrary()'' before use ([[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing\|see details]]), especially as BOOPSI classes are usually not included into the list of libraries opened automatically. '''This is not the case for MUI classes''' however. MUI shared classes can be used without opening them. It is explained below, in the [[Short_BOOPSI_Overview#MUI_Extensions_to_BOOPSI\|MUI Extensions to BOOPSI]] section.
		+

	==Methods and Attributes==		==Methods and Attributes==

@@ Line 17: / Line 17: @@
 A class defines a set of methods available for its objects (instances) by the set of ''case'' statements in the dispatcher. Object's attributes are set using the ''OM_SET()'' method and are gotten using ''OM_GET()''. The attributes may also be passed to the object constructor directly. The set of attributes for a class and applicability of the attributes are then defined by the source code of ''OM_NEW()'' (the constructor), ''OM_SET()'' and ''OM_GET()'' methods. There is no formal declaration of class. There is also no division between public and private methods and attributes. Some kind of formal declaration and levels of access may be imposed by putting every class in a separate source code file. An accompanying header file would contain definitions of method identifiers, attribute identifiers and method parameters structures, but only those considered "public". Private method identifiers should be defined inside the source code of the class, so they are not visible outside of the class source code.
-A BOOPSI class can be shared between applications. All the MUI built-in classes are shared ones. The BOOPSI maintains a system-wide list of public classes (the list can be browsed with the ''Scout'' monitoring tool). Shared classes are identified by names. A part of the MUI standard classes is contained inside the main MUI library &ndash; ''muimaster.library''. The library adds these classes to the system list when opened for the first time. The rest of the MUI standard classes are stored on the system disk partition in the ''MOSSYS:Classes/MUI/'' directory. Additional third party classes may be placed in the ''SYS:Classes/MUI'' directory.
+A BOOPSI class can be shared between applications. All the MUI built-in classes are shared ones. The BOOPSI maintains a system-wide list of public classes (the list can be browsed with the ''Scout'' monitoring tool). Shared classes are identified by names. A part of the MUI standard classes is contained inside the main MUI library &ndash; ''muimaster.library''. The library adds these classes to the system list when opened for the first time. The rest of the MUI standard classes are stored on the system disk partition in the ''MOSSYS:Classes/MUI/'' directory. Additional third party classes may be placed in the ''SYS:Classes/MUI/'' directory.
 Shared classes use the MorphOS shared library framework, in other words a shared BOOPSI class is just a kind of shared library. The class adds itself to the public list of classes, when it is opened from disk. As such, a BOOPSI shared class should be opened with ''OpenLibrary()'' before use ([[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing|see details]]), especially as BOOPSI classes are usually not included into the list of libraries opened automatically. '''This is not the case for MUI classes''' however. MUI shared classes can be used without opening them. It is explained below, in the [[Short_BOOPSI_Overview#MUI_Extensions_to_BOOPSI|MUI Extensions to BOOPSI]] section.

@@ Line 138: / Line 138: @@
 ==Object Construction==
-Having a class, the programmer can create an unlimited number of objects (instances) of this class. Every object has its own instance data area, which is allocated and cleared automatically by the BOOPSI. Of course only object data are allocated for every instance. The code is not duplicated, so it must be reentrant (static variables and code self-modification must not be used).
+Having a class, the programmer can create an unlimited number of objects (instances) of this class. Every object has its own instance data area, which is allocated and cleared automatically by the BOOPSI. Of course only object data are allocated for each instance. The code is not duplicated, so it must be reentrant (static variables and code self-modification must not be used).
-Objects are created and disposed with two special methods: the constructor, ''OM_NEW()'' and the destructor, ''OM_DISPOSE()''. Of course the constructor method cannot be called on an object, because it creates a new one. It needs a pointer to the object's class instead, so it cannot be invoked with ''DoMethod()''. The ''intuition.library'' provides ''NewObjectA()'' and ''NewObject()'' functions for calling the constructor. The difference between them is that ''NewObjectA()'' takes a pointer to a [[Taglists|taglist]] specifying initial values for objects. ''NewObject()'' allows to build this taglist from variable number of function arguments.
+Objects are created and disposed with two special methods: the constructor, ''OM_NEW()'' and the destructor, ''OM_DISPOSE()''. Of course the constructor method cannot be called on an object, because it creates a new one. It needs a pointer to the object's class instead, so it cannot be invoked with ''DoMethod()''. The ''intuition.library'' provides ''NewObjectA()'' and ''NewObject()'' functions for calling the constructor. The difference between them is that ''NewObjectA()'' takes a pointer to a [[Taglists|taglist]] specifying initial values for objects. ''NewObject()'' allows the programmer to build this taglist from a variable number of function arguments.
-''NewObject[A]()'' has two alternative ways of specifying the created object's class. Private classes are specified by pointers of ''Class'' type. Shared classes are specified by name, which is a null-terminated string. If the pointer is used for class specification, the name should be NULL, if the name is used, the pointer should be ''NULL''. Four examples below show creating instances of private and public class with both ''NewObjectA()'' and ''NewObject()'':
+''NewObject[A]()'' has two alternative ways of specifying the created object's class. Private classes are specified by pointers of ''Class'' type. Shared classes are specified by name, which is a null-terminated string. If the pointer is used for class specification, the name should be NULL, if a name is used, the pointer should be ''NULL''. Four examples below show creating instances of private and public class with both ''NewObjectA()'' and ''NewObject()'':
   Object *obj;
@@ Line 175: / Line 175: @@
   TAG_END);
-''NewObject[A]()'' returns ''NULL'' in case of an object creation failure. Usual reasons are: wrong class pointer/name, lack of free memory, wrong/missing initial values of attributes. The return value of ''NewObject[A]()'' should be always checked in the code.
+''NewObject[A]()'' returns ''NULL'' in case of an object creation failure. Usual reasons are: wrong class pointer/name, lack of free memory, wrong/missing initial values of attributes. The return value of ''NewObject[A]()'' should always be checked in the code.
@@ Line 191: / Line 191: @@
 ==MUI Extensions to BOOPSI==
-The Magic User Interface not only builds on BOOPSI but also extends it. Except of providing a broad set of classes, MUI also modifies BOOPSI mode of operation a bit. Two modifications are discussed in this chapter: extension of the ''IClass'' structure and own functions for object construction and destruction.
+The Magic User Interface not only builds on BOOPSI but also extends it. Other than providing a broad set of classes, MUI also modifies the BOOPSI mode of operation a bit. Two modifications are discussed in this chapter: extension of the ''IClass'' structure and MUI's own functions for object construction and destruction.
-MUI uses ''MUI_CustomClass'' structure for its internal class representation. This structure contains the standard ''Class'' one inside. It is important when creating objects of MUI private classes with ''NewObject()'', that the ''Class'' structure must be extracted from the ''MUI_CustomClass'' one:
+MUI uses the ''MUI_CustomClass'' structure for its internal class representation. This structure contains the standard ''Class'' structure inside. It is important when creating objects from MUI private classes with ''NewObject()'', that the ''Class'' structure must be extracted from the ''MUI_CustomClass'' structure:
   struct MUI_CustomClass *priv_class;
@@ Line 200: / Line 200: @@
   obj = NewObject('''priv_class->mcc_Class''', NULL, /* ... */ TAG_END);
-The second modification of BOOPSI is using own functions for object construction and destruction, ''MUI_NewObject[A]()'' and ''MUI_DisposeObject()'' respectively. These two functions are used '''only''' for objects of MUI shared (public) classes. Objects of private classes are created with ''NewObject()'' as shown above. The main advantage of ''MUI_NewObject()'' is automatic opening and closing disk based shared classes. Here is some example:
+MUI's second modification of BOOPSI is using its own functions for object construction and destruction, ''MUI_NewObject[A]()'' and ''MUI_DisposeObject()'' respectively. These two functions are used '''only''' for objects of MUI shared (public) classes. Objects of private classes are created with ''NewObject()'' as shown above. The main advantage of ''MUI_NewObject()'' is automatic opening and closing of disk based shared classes. Here is an example:
   Object *text;
@@ Line 206: / Line 206: @@
   text = MUI_NewObject(MUIC_Text, MUIA_Text_Contents, "foobar", TAG_END);
-'''MUIC_Text'' is a macro defined in the ''<libraries/mui.h>'' and it expands to "Text.mui" string. All MUI public classes should be referenced by their ''MUIC_'' macros rather than direct string literals. It helps to detect mistyped classes names, as a typo in a macro will be detected during compilation. The MUI checks if a class named ''Text.mui'' is added to the public list of classes. If not, the class is found on disk, opened and used for creating the requested object. Closing the class when no longer in use is handled automatically too. All MUI objects should be disposed using ''MUI_DisposeObject()'', which takes the object to be disposed as its only argument, the same as ''DisposeObject()''.
+'''MUIC_Text'' is a macro defined in ''<libraries/mui.h>'' and it expands to "Text.mui" string. All MUI public classes should be referenced by their ''MUIC_'' macros rather than by direct string literals. It helps to detect mistyped class names, as a typo in a macro will be detected during compilation. The MUI checks if a class named ''Text.mui'' has been added to the public list of classes. If not, the class is found on disk, opened and used for creating the requested object. Closing the class when no longer in use is handled automatically too. All MUI objects should be disposed using ''MUI_DisposeObject()'', which takes the object to be disposed as its only argument, the same as ''DisposeObject()''.
   MUI_DisposeObject(text);

@@ Line 87: / Line 87: @@
 The ''OM_SET()'' method returns the number of attributes applied to the object. If some attributes are not known to the object's class (and superclasses), they are not counted. This return value is usually ignored, it may be used for testing an attribute applicability.
-MUI provides a few additional methods for setting attributes, namely ''MUIM_Set()'', ''MUIM_NoNotifySet()'' and ''MUIM_MultiSet()''. They are mainly used in [[notifications]] and are discussed in the [[Notifications|relevant chapter]].
+MUI provides a few additional methods for setting attributes, namely ''MUIM_Set()'', ''MUIM_NoNotifySet()'' and ''MUIM_MultiSet()''. They are mainly used in [[Event_Driven_Programming,_Notifications#Notifications_in_MUI|notifications]].
 ====Getting an Attribute====

@@ Line 94: / Line 94: @@
   LONG value1;
-  QUAD value 2;    /* 64-bit signed integer */
+  QUAD value2;    /* 64-bit signed integer */
   STRPTR *value3;

@@ Line 19: / Line 19: @@
 A BOOPSI class can be shared between applications. All the MUI built-in classes are shared ones. The BOOPSI maintains a system-wide list of public classes (the list can be browsed with the ''Scout'' monitoring tool). Shared classes are identified by names. A part of the MUI standard classes is contained inside the main MUI library &ndash; ''muimaster.library''. The library adds these classes to the system list when opened for the first time. The rest of the MUI standard classes are stored on the system disk partition in the ''MOSSYS:Classes/MUI/'' directory. Additional third party classes may be placed in the ''SYS:Classes/MUI'' directory.
-Shared classes use MorphOS shared library framework, in other words a shared BOOPSI class is just a kind of shared library. The class adds itself to the public list of classes, when it is opened from disk. As such, a BOOPSI shared class should be opened with ''OpenLibrary()'' before use ([[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing|see details]]), especially as BOOPSI classes are usually not included into the list of libraries opened automatically. '''This is not the case for MUI classes''' however. MUI shared classes can be used without opening them. It is explained below, in the [[Short_BOOPSI_Overview#MUI_Extensions_to_BOOPSI|MUI Extensions to BOOPSI]] section.
+Shared classes use the MorphOS shared library framework, in other words a shared BOOPSI class is just a kind of shared library. The class adds itself to the public list of classes, when it is opened from disk. As such, a BOOPSI shared class should be opened with ''OpenLibrary()'' before use ([[MorphOS_API_and_Its_Organization#Manual_Library_Opening_and_Closing|see details]]), especially as BOOPSI classes are usually not included into the list of libraries opened automatically. '''This is not the case for MUI classes''' however. MUI shared classes can be used without opening them. It is explained below, in the [[Short_BOOPSI_Overview#MUI_Extensions_to_BOOPSI|MUI Extensions to BOOPSI]] section.
 ==Methods and Attributes==

← Older revision		Revision as of 13:33, 15 November 2010
Line 207:		Line 207:
	text = MUI_NewObject("text.mui", MUIA_Text_Contents, "foobar", TAG_END);		text = MUI_NewObject("text.mui", MUIA_Text_Contents, "foobar", TAG_END);

−	MUI checks if a class named ''text.mui'' is added to the public list of classes. If not, the class is found on disk, opened and used for creating the requested object. Closing the class when no longer in use is handled automatically too. All MUI objects should be disposed using ''MUI_DisposeObject()'', which ~~just~~ takes the object to be disposed as its only argument.	+	MUI checks if a class named ''text.mui'' is added to the public list of classes. If not, the class is found on disk, opened and used for creating the requested object. Closing the class when no longer in use is handled automatically too. All MUI objects should be disposed using ''MUI_DisposeObject()'', which takes the object to be disposed as its only argument, the same as ''DisposeObject()''.
		+
		+	MUI_DisposeObject(text);