sources

> Hello,
>
> not sure if this is a good idea, but it came to my mind (thinking
> about classical Smalltalks' img.sources file): should the code be
> packaged as it is now - pkg.js and pkg.deploy.js, where code is
> redundant, just in the first case it has additional info for IDE? What
> about saving those two infos separately - foo.js for classes and
> methods only (as now in .deploy.js) and foo.meta.js for IDE metadata
> (category, args, source, messageSends, referencedClasses)? IDE can
> then load the additional info itself, and if IDE is not run, it is not
> loaded.
>
> Herby

> Herby Vojčík<[hidden email]>  writes:
>
> Hi!
>
> The IDE uses this infos, but it's not just infos for the IDE. I would
> expect to load all the infos, including the source code, when running
> the REPL or running Amber on top of node.js for instance. In fact, I
> would want all the infos all the time except for deployment. That's
> why I think the *.js files should stay as they are.
>
> I see the *.deploy.js files as a convenience for deployment, nothing
> more. We could think about not generating them automatically and produce
> them through bin/amberc, but I think it's convenient this way.
>
> Cheers,
> Nico
>
>> Hello,
>>
>> not sure if this is a good idea, but it came to my mind (thinking
>> about classical Smalltalks' img.sources file): should the code be
>> packaged as it is now - pkg.js and pkg.deploy.js, where code is
>> redundant, just in the first case it has additional info for IDE? What
>> about saving those two infos separately - foo.js for classes and
>> methods only (as now in .deploy.js) and foo.meta.js for IDE metadata
>> (category, args, source, messageSends, referencedClasses)? IDE can
>> then load the additional info itself, and if IDE is not run, it is not
>> loaded.
>>
>> Herby