[Mono-osx] [MonoMac] patch for MM-addin, Existing Framework

[Michael Hutchinson]

On Thu, Jan 27, 2011 at 9:12 AM, Duane Wandless <duane at wandless.net> wrote:
> Throwing may be better if the framework is missing.  I can be convinced.
> No symlinking for now.
> The "relative path" option is only while developing and has no impact when
> running.  Once installed into Contents\Frameworks the reference is always
> relative to the app location.

Not sure what you mean by this, what is the "relative path option"?

> Incorporated most of your suggestions, out of time now have to get back to
> the day job.  Also added the ability for the project pad to update as
> frameworks are added/deleted.  This is the same basic method Web References
> uses.
> Did not move the generation of the file to OnBuild.  But it is better about
> not requiring a build every time.

I think there's a misunderstanding here. I didn't mean you should move
to to MonoMacProject.OnBuild. It's already *in*
MonoMacBuildExtension.OnBuild. I meant it should move to the point in
MonoMacBuildExtension.OnBuild before base.OnBuild, since base.OnBuild
is where the compilation happens.

The BuildExtension chain concept isn't obvious and isn't really
documented. Basically, MD creates a set of all the BuildExtensions
that are valid for the current project, ordered by their position in
the addin tree, and creates a "chain" - the base implementation of
each virtual method in the BuildExtension calls the next class in the
chain. Somewhere way down in the chain past the MonoMacBuildExtension,
there's a BuildExtension subclass where OnBuild actually does the
compilation. So code in MonoMacBuildExtension.OnBuild that's before
the base.OnBuild call is run before the compile, and code after the
base.OnBuild call is run after the compile. Does that make sense?

> The generated path in the dlopen call is almost correct.  Currently it is
> the FULL path to the <proj>.app\Contents\Frameworks location.  Which is
> incorrect.  The call to dlopen should be relative to the .app's location.
> Including the new files.
> Even though I disagree in part to the overuse of var I did modify this code
> to use it more.
> I disagree with using var when the type is known.  To me that is exactly
> when you should not use var and diminishes one of C#'s benefits, strong name
> typing.  At least from readability.
> I agree with this summary from http://www.infoq.com/news/2008/05/CSharp-var:
>
> Overuse of var can make source code less readable for others. It is
> recommended to use var only when it is necessary, that is, when the variable
> will be used to store an anonymous type or a collection of anonymous types.
>
> For example this line is completely vague:
> var ls = conf.LaunchScript;
> I do not know what ls is.  What is a LaunchScript, oh if I hover over it I
> see it is a FilePath.  To be me that would much more readable and useful as:
> FilePath ls = conf.LaunchScript;
> That makes the code clear just from a glance.  Otherwise I have to research
> to determine the type.  Maybe if you limit the use to var foo = new Foo ().
>  But not everywhere especially when the assignment is vague.

I definitely agree in principle, that's why I said "when the type is
obvious from the assignment". When it is obvious, var makes the code
more readable :)

Though as you noticed above, I sometimes get lazy when type is obvious to me...

- Michael

-- 
Michael Hutchinson
http://mjhutchinson.com