* native values in objects from c @ 2006-08-29 11:50 Michael Wohlwend 2006-08-29 13:05 ` [Caml-list] " Jacques Garrigue 0 siblings, 1 reply; 5+ messages in thread From: Michael Wohlwend @ 2006-08-29 11:50 UTC (permalink / raw) To: caml-list with that code: class x = object val name = "hoho" end;; let ho = new x in ... how do I access the field name form C? The docu says it should be the third field of the block, but that doesn't work for me (it has Tag 0, not 252 for strings ...) cheers, Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] native values in objects from c 2006-08-29 11:50 native values in objects from c Michael Wohlwend @ 2006-08-29 13:05 ` Jacques Garrigue 2006-08-29 14:07 ` Michael Wohlwend 0 siblings, 1 reply; 5+ messages in thread From: Jacques Garrigue @ 2006-08-29 13:05 UTC (permalink / raw) To: micha-1; +Cc: caml-list From: "Michael Wohlwend" <micha-1@fantasymail.de> > with that code: > > class x = object > val name = "hoho" > end;; > > let ho = new x in ... > > > how do I access the field name form C? > > The docu says it should be the third field of the block, but that doesn't work for me (it has Tag 0, not 252 for strings ...) Well, since fields start at 0, the 3rd field is number 2. # Obj.size (Obj.repr ho);; - : int = 3 # Obj.tag (Obj.field (Obj.repr ho) 2);; - : int = 252 Jacques Garrigue ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] native values in objects from c 2006-08-29 13:05 ` [Caml-list] " Jacques Garrigue @ 2006-08-29 14:07 ` Michael Wohlwend 2006-08-31 6:55 ` Jacques Garrigue 0 siblings, 1 reply; 5+ messages in thread From: Michael Wohlwend @ 2006-08-29 14:07 UTC (permalink / raw) To: Jacques Garrigue; +Cc: caml-list -------- Original-Nachricht -------- > > Well, since fields start at 0, the 3rd field is number 2. thanks for helping; actually my fault was to think the elements are linear ordered, even if the class is inherited (I want to get the first value of the base). The values are ordered reverse of definition, whereas the docu says: "Instance variables are stored in the order in which they appear in the class definition" In the end I want to hide public methods which give you access the the pointer to the c++ object and hiding an external method is easy. cheers Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] native values in objects from c 2006-08-29 14:07 ` Michael Wohlwend @ 2006-08-31 6:55 ` Jacques Garrigue 2006-08-31 8:22 ` Michael Wohlwend 0 siblings, 1 reply; 5+ messages in thread From: Jacques Garrigue @ 2006-08-31 6:55 UTC (permalink / raw) To: micha-1; +Cc: caml-list From: "Michael Wohlwend" <micha-1@fantasymail.de> > > Well, since fields start at 0, the 3rd field is number 2. > > thanks for helping; actually my fault was to think the elements are linear ordered, even if the class is inherited (I want to get the first value of the base). The values are ordered reverse of definition, whereas the docu says: > "Instance variables are stored in the order in which they appear in the class definition" > > In the end I want to hide public methods which give you access the the pointer to the c++ object and hiding an external method is easy. Aargh, you're right. The behaviour changed between 3.08 and 3.09. In 3.08, fields are still ordered in definition order, including inherited ones, but in 3.09, due to an optimization, inherited fields appear after newly defined ones. The trouble is that this being due to an optimization, this may change again, so it is not a good idea to depend on it. Note also that it is pretty easy to define another object, with the same type as the one you want to interface with C++, but with completely different fields. I.e., accessing object fields from the C side is always dangerous. A better approach it to add a method which returns the field with an abstract type, this way users cannot break the type system. Jacques Garrigue ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Caml-list] native values in objects from c 2006-08-31 6:55 ` Jacques Garrigue @ 2006-08-31 8:22 ` Michael Wohlwend 0 siblings, 0 replies; 5+ messages in thread From: Michael Wohlwend @ 2006-08-31 8:22 UTC (permalink / raw) To: Jacques Garrigue; +Cc: caml-list -------- Original-Nachricht -------- Datum: Thu, 31 Aug 2006 15:55:12 +0900 (JST) Von: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp> An: micha-1@fantasymail.de Betreff: Re: [Caml-list] native values in objects from c > Aargh, you're right. The behaviour changed between 3.08 and 3.09. > In 3.08, fields are still ordered in definition order, including > inherited ones, but in 3.09, due to an optimization, inherited fields > appear after newly defined ones. The trouble is that this being due > to an optimization, this may change again, so it is not a good idea to > depend on it. o.k., accessing the field from c allready seemed hacky to me :-) > A better approach it to add a method which returns the field with an > abstract type, this way users cannot break the type system. o.k., seems indeed the safer way. thanks, Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-08-31 8:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-08-29 11:50 native values in objects from c Michael Wohlwend 2006-08-29 13:05 ` [Caml-list] " Jacques Garrigue 2006-08-29 14:07 ` Michael Wohlwend 2006-08-31 6:55 ` Jacques Garrigue 2006-08-31 8:22 ` Michael Wohlwend
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox