[nem-en] ManagerClass.Instance == pain!

Kamil Skalski kamil.skalski at gmail.com
Sun Nov 19 01:02:32 CET 2006


> > and breaking much of API and making its using harder. Moreover,
> > it would in general require all code quotations to be used only where
> > special "compiler context" is available, so requiring macro writers to
> > pass this context to every utility function they use.
>
> I thin, all utility function need convert into method of this context. It
> will be useful for IDE support (code completion).
>

I mean that for example you have a macro:

macro Generate (specification1, specification2) {
  def code1 = Utility.Generate1 (specification1);
  def code2 = Utility.Generate2 (specification2);
  <[ $code1 + $code2 ... ]>
}

module Utility {
  public Generate1 (expr : PExpr) : PExpr {     ...     }
   private myUtil (expr:PExpr):PExpr {  }
  ...
}


you would need to transform the Utility module to take the context into account:

macro Generate (specification1, specification2) {
  def code1 = Utility.Generate1 (Macros.Manager(), specification1);
  def code2 = Utility.Generate2 (Macros.Manager(), specification2);
  <[ $code1 + $code2 ... ]>
}

module Utility {
  public Generate1 (mgr:ManagerClass, expr : PExpr) : PExpr {     ...     }
   private myUtil (mgr:ManagerClass, expr:PExpr):PExpr {  }
  ...
}

and pass it everywhere...

It would break literally ALL existing code.

The need to pass context around is quite disturbing in my opinion...
Every time you would like to create simple  Location or PExpr object
you need to have ManagerClass at hand... Of course we could force
users to do this and fix all code in nemerle sources, but the question
is if it is really worth all the costs?

-- 
Kamil Skalski
http://nazgul.omega.pl



More information about the devel-en mailing list