Exactly your example of pushing a new controller DOES to my experience and knowledge keep a reference. No need for a class reference. In fact in most situations the reference is kept (where possible) and if not, it is a bug in Monotouch. That's how it was explained to me by Sebastien and Rolf.
Grüße, René Am 15.01.2012 um 23:54 schrieb Jackson Harper <[email protected]>: > > I agree that this is a problem. But its not the garbage collector, it is just > doing its job. The problem is, that many of the APIs that you would expect > to hold a managed ref to your objects do not. To do things in a ".NETy" kind > of way, I would expect something like: > > PushViewController (new MyController ()) to hold a reference to the new > MyController > > Jackson > > > On Sun, Jan 15, 2012 at 5:23 PM, rnendel <[email protected]> wrote: > This is going to sound negative, but for all of us Monotouch enthusiasts, > please read between the lines at the heart of the issue and not just read it > as "flaming" - for monotouch developers, please just read. > ------- > The changes to the garbage collector have got to get fixed. Getting tired > of chasing <unrecognized selector sent to instance> exceptions. Not all > variables can be declared and/or initialized at class scope (that seems to > be the "quick fix" given out for the problem, but really doesn't solve much) > and I have seen zero productive feedback to anyone reporting the issue > (which many have). > > Part of the c# pattern is a reliable garbage collector that behaves in a > predictable manner. The use of lambda expressions and a reliance on > predictable behavior based on reference count is a key part of what c# is > all about. Requiring variables to be declared at class scope, or allowing > these exceptions to continue with "quick fix" suggestions really doesn't > help much - we're talking about "core language functionality" here, not > optional features. > > The attractiveness of c# over objective C is NOT just the language > semantics/framework, but also the behavior of the backend components, such > as a reliable garbage collector. This is c# not a "kinda c# hack" right? > The objective of MT is a "quicker learning curve" by removing the > Objective-C component. However, if the development pattern must change (and > take more time tracking down bugs) because of faulty behavior, then the > "value add" of MT is greatly reduced. > > So, please, do something about this or many people coming from stable c# > elsewhere will start to believe that learning Objective-C really isn't such > a bad thing after all. MT is designed to attract existing c# developers, > but if the MT c# implementation and run-time behavior does not match or come > close to what c# developers would expect will they have a "positive" > experience or a negative one. > -------- > Again, to all those who would respond as MT enthusiasts - believe me, I can > imagine what you'll say, so please don't trash up the thread with flame @ > me, or whatever. The garbage collector is a real problem right now and has > gotta get fixed. And, no, I'm not a noob - been developing in MT for over a > year and have 20+ years professional development under my belt (mostly in > the PC/console games industry). I simply want this solution to "work" as > expected for the language being used, as do we all I would assume. > > So, devs, please respond and let's get some information going on the garbage > collector changes. Which of the various errors reported are *really* due to > an IOS bug and which are due to the collector. So far it is all very vague > and no real information about a "fix" has been provided that I can tell. > I'd ask that you stop addressing specific scenarios, like "when I click my > button I get an <unrecognized selector> in the event handler" and begin > addressing the overall issue, which is the garbage collector. > > Thanks. > > -- > View this message in context: > http://monotouch.2284126.n4.nabble.com/Unknown-selector-and-garbage-collection-tp4297921p4297921.html > Sent from the MonoTouch mailing list archive at Nabble.com. > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch > > _______________________________________________ > MonoTouch mailing list > [email protected] > http://lists.ximian.com/mailman/listinfo/monotouch
_______________________________________________ MonoTouch mailing list [email protected] http://lists.ximian.com/mailman/listinfo/monotouch
