[Mono-list] Mono and the OS/X Port

[John Duncan]

Yes, you're right. I am working on it. Here's where I am:

I have a PB project building mint and libmono (actually, a Framework I 
called mono-cocoa). Mint seems to run but I haven't made it able to run 
mcs.exe. This gives me the tough task of narrowing down mcs.exe by 
building it on Linux until I find where the weakness in mint is. 
Nonetheless, I think I have most of the bugs in the native interface 
worked out and it should only be a matter of time.

I would appreciate help anywhere along the line. Let me know and I'll 
try to package up what I've got. It's a little bit different from the 
basic mono build and it's not production quality.

Anyhow, my goal is to eventually provide a usable runtime for OS X that 
acts in quite a native capacity. I'd like to adopt something similar to 
the approach used for MRJ. This means that the Mono runtime should 
eventually be able to tie in to the Obj-C Cocoa objects and there will 
also be a packager for wrapping up Mono applications in a .app bundle.

I've been working really slowly, though, because I'm on vacation. Having 
someone else egging me along will probably help me to move more quickly.

John

On Tuesday, September 10, 2002, at 11:50 AM, Steve Mentzer wrote:

>
> As of right now, there is little information on the main go-mono web 
> site that indicates that an OS/X port is even being attempted. At 
> least, I was unable to locate any such information...
>
> In any case, after reading the digests, I discovered that an OS/X port 
> is being attempted.... by at least one person.
>
> I am a new windows->mac switchee who has been developing production 
> software with the MS .net implementation(s) since beta 2. I am eager to 
> begin working on the mono/osx port in whatever capacity.
>
> Given that a large number of MacOS/X developers have been asking where 
> the .net implementation is, would it be wise to extend the existing 
> go-mono web site to include information about the os/x specific port?
>
> I know the demand is there. Droves of my penguin-loving bretheren are 
> beginning to feel the pull of OS/X. I believe there is a historic 
> opportunity to create a viable alternative to IIS for hosting XML web 
> services on a commercially viable *desktop* platform.
>
>
>
>
>
>
>
>
> -----Original Message-----
> From: Jonathan Pryor [mailto:jonpryor@vt.edu]
> Sent: Tuesday, September 10, 2002 8:50 AM
> To: Mono List
> Subject: Re: [Mono-list] Question about C#
>
>
> Inline...
>
> On Mon, 2002-09-09 at 23:49, Ricardo Kirkner wrote:
>
> <snip/>
>             2. If I want to overload the ++ operator in a class that I
>             dont want to be public, but internal or private, how can I
>             prevent someone from accessing a method (the ++ operator)
>             that has been defined public?
>         Question to ponder: how will they access the public method if
>         they can't access the class in the first place?  Consider
>         methods that must be public, such as Object.ToString().  Is it a
>         problem that this method is public, even in your internal
>         classes?  Not usually -- non-internal users can't access the
>         class, so the existence of a public ToString() method shouldn't
>         be a problem.  The same should be true of any operators.
>
>         (The answer to the above question of accessing internal classes
>         is simple, actually: use Reflection and poke around...
>         Alternatively, modify the runtime to permit poking on internal
>         data.  It's hard to protect against the runtime....  However,
>         these ideas are not trivial, and can probably be ignored most of
>         the time.)
>     This is not really a clean solution, is it? I mean, although I
>     cannot access the class (so I dont have to worry about the
>     "public-nes" of the methods inside that class, it does not mean that
>     it is correct to force you to declare the method public. (although
>     this could be, and probably is, just a simplification made by the
>     language designers)
>
> Again, I'm not sure why operators need to be public.  However, the
> reason for requiring that overridden methods not change the access
> specifiers is to minimize confusion.  Through polymorphism, you're able
> to invoke a derived class implementation through a reference to a base
> class.  Wouldn't it be weird if you couldn't invoke the same method
> through a reference to the derived class?  Consider the following
> C#-like code:
>
>     class Base {
>         public virtual void Calculate () {/* ... */}
>     }
>
>     class Derived : Base {
>         // Note: change protection; not allowed in C#
>         protected override void Calculate () { /* ... */ }
>     }
>
>     class User {
>         public static void Main () {
>             Base b = new Derived ();
>
>             // Legal; method is public
>             b.Calculate ();
>
>             Derived d = new Derived ();
>
>             // Not legal; method is protected!
>             d.Calculate ();
>         }
>     }
> Requiring that overridden methods provide the same access specifiers as
> the base method can be seen as a simplification of the language.  It can
> also be seen as a sane requirement, reducing programmer confusion in
> situations like the example above.
>
>         However, the real question remains: why do you need an
>         assignment operator?  Assignment operators are useful in C++
>         when wrapping resources, such as memory, files, thread locks,
>         etc., to make sure that the resource is properly managed (in
>         concert with the copy constructor and destructor)...  In C#, the
>         garbage collector is used for resource management, removing
>         (what I've found) the greatest need for the trio of C++ copy
>         constructor, assignment operator, and destructor.  If you need
>         something more deterministic, the IDisposable interface/idiom is
>         appropriate.
>
>     I actually dont have a need for an assignment operator, but I think
>     it is really nice if you can do something like
>
>         obj1 = obj2;
>
>     instead of
>
>         obj1 = new ObjectType(obj2);
>
>     This whole issue arises because c# treats objects as references to
>     objects instead as the real ones (not that I find this wrong). I
>     think that if you use a language that tries to be so simple as c#
>     is, and that tries to "help" the programmer by simplifying syntax,
>     etc, then it is suspicious not being able to write a simple object
>     assignment  (without having both variables referencing the same
>     object. Note that by simle I mean using the = operator). This
>     could be just a decision made by the folks who thought about the
>     language (and then I could not make anything about it, of course),
>     so I dont want to make a big discussion about this here (because it
>     is really a C# topic and not mono specific).
>
> Simplicity is often achieved by removing features.  Java is often
> considered to be simple because it removed multiple inheritance,
> operator overloading, enumerations, templates, and lots of other fun C++
> features.  In comparison, C# is considerably less simple than Java, but
> still simpler than C++.  For example, C# followed the Simula-like (and
> Java-like) bifurcation of the type system.  You have stack-allocated
> types, and heap-allocated types, and never the two shall meet.  (This is
> true for Simula and Java, but C# lets you convert the stack-allocated
> objects into heap-allocated objects, bridging the type system.  You
> still can't have any object-type be located on the stack, though.)
> Stroustrup hated this bifurcation, which is why C++ (by default) allows
> objects to be allocated anywhere.  However, C++'s flexibility leads to
> complexity.  The ability to store any object anywhere, coupled with the
> lack of a garbage collector, requires that the programmer be much more
> involved with the lifetime of objects than is required in other
> programming languages.
>
> So .NET simplified things by allowing programmers to have a choice
> between two allocation functions: stack based types (structures), or
> heap-allocated reference types (everything else).  By limiting the
> choices they simplified the language, simplified run-time semantics, and
> allowed for more general optimizations in the runtime.  (For example,
> all copying can be done through bitwise copy operations, increasing
> performance.)  Programming flexibility was less of a requirement than
> simplification, that's all.
>
> Thus we have one form of assignment -- bitwise copy -- with two sets of
> semantics.  Structure assignment, which copies the whole structure, and
> reference assignment, which copies a reference to the actual object.
>
> As you put it, it's just a decision made by the folks who thought about
> the language and the runtime.  I'm sure they had more reasons than the
> above behind their decision, but it was still their decision.
>
>     Finally, I want to thank you Jonathan, for your comments, I believe
>     they helped
>
>     With regards,
>
>     Ricardo Kirkner
>
> - Jon
>
>
>
>
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
>
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list