Changes in commit

I am going nuts that each release commits files in different way.
The current release makes the following PUT calls:
  /namespace/package.js
  /namespace/_source/package.st

Is there any documentation on it.
Will it stabilize at some point in time.
Thanks

This is related to changing the namespace.
What's the best practice changing the namespace?

Imagine you create packages with 'namespaceA'.
Later you want to change the namespace to 'namespaceB'.

Changing
smalltalk.initialize({ 'transport.defaultAmdNamespace': 'namespaceA' });
to
smalltalk.initialize({ 'transport.defaultAmdNamespace': 'namespaceB' });

works fine. The codes are loading from namespaceA, but commiting to namespaceB leads to the above mentioned PUT calls.
Any advise on that?

You are NOT supposed to change namespaces. I repeat, NOT. This is why you have to choose it carefully at the beginning.

Changing namespace is tedious task. First, you should have mappings for old as well as nerw namespace in .html. Then, in IDE, change the namespace via

  (Package named: 'foo') transport namespace: 'new_namespace'.

Then commit the changed package; and also all the packages that depend on it, since they must update the dependency (this is why the namespace must be stable).

After you find (with some grep `find` or Find in path... or something like that) that there is no link to your old namespace beyond the mapping in .html, remove the old mapping and you should be done.

Herby

laci wrote:
> This is related to changing the namespace.
> What's the best practice changing the namespace?
>
> Imagine you create packages with 'namespaceA'.
> Later you want to change the namespace to 'namespaceB'.
>
> Changing
> smalltalk.initialize({ 'transport.defaultAmdNamespa
ce': 'namespaceA' });
--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Herby,
What about changing namespace references within the JS file?
That should be a way to modify namespace.

That means loading sources with different namespaces also goes in the NOT category.
I think it will work unless you commit changes to any packages.

laci wrote:
> Herby,
> What about changing namespace references within the JS file?

You can do it that way if you wish. It is not good (see below), but it's your code.

> That should be a way to modify namespace.

That shouldn't be the way to change namespace. It's brittle.

IDE does much better work for you, since it knows you changed the namespace and commits the new name for the package itself but also for packages that depend on the package.

Alternatively, you can use `amberc` and `-n` parameter to compile a bunch of .st into different namespace.

And besides, you should _not_ change namespaces. You will break any client code that depends on you (and it can be foreign code, not just yours). Simply do not change them. That's why it is stressed to choose good namespace at the beginning, avoiding nameclashes. And if you do change them, then do it occasionally, and let all users know in advance; possible only if you change major version number.

> That means loading sourc
es with different namespaces also goes in the NOT
> category.

Loading from multiple namespace works perfectly. Just map multiple namespaces,
and you load from them.

What is the problem you see in loading from multiple namespaces?

Amber loading and packaging was _designed_ so that it can load multiple namespaces.

> I think it will work unless you commit changes to any packages.

Saving to multiple namespaces works as well, except the cross-domain security issues, which are not amber-related, that is, you can only save those packages that are at the same domain than you .html.

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Thanks for your valuable info.

Hi,

Herby's answer quite clear, but I'd like to clarify the changes made in
latest releases of Amber.

We moved form homemade packages to AMD modules. It's in itself a very
good move, and allows us to leverage a lot of what already exists, and
play well with others. That said, it was not without some important
changes, and yes, the API changed also quite a bit, and twice.

It might change again in the future as we try and find the best way to
do it (and it is not as simple as it may look). But we'll make it
backward compatible and deprecate things slowly.

Amber hasn't reached v1.0 yet, after which point such backward
incompatible changes will be mostly forbidden unless we change the major
version number.

I hope this explains a bit the recent API changes and what you can
expect in the future :)

Cheers,
Nico

laci writes:


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Nicolas Petton wrote:
> Hi,
>
> Herby's answer quite clear, but I'd like to clarify the changes made in
> latest releases of Amber.

I think the importance of choosing a good namespace from the beginning (because it is virtually impossible to change without hurting the client, which is especially important for a library) is not explained / stressed enough in the docs.

It should be pointed that the it's important and probably explained why.

It looks like lot of users have chosen "just something that works for the moment" (like 'roamber' in roassal for amber), and do not think about the fact the once it began to be used, the name should stick.

> Cheers,
> Nico

Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

True. Since we're writing a proper doc, it's time to add it then!

Nico

Herby Vojčík writes:


--
Nicolas Petton
http://nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.

Basically the defaultAmdNamespace identifies the namespace for newly created packages:
        smalltalk.initialize({ 'transport.defaultAmdNamespace': 'kv_sysadmin' });

Next:
        // Configure require path for own packages - multiple namespaces supported
        require.config({ paths: {
          'kv_sysadmin': 'amber-projects/kv_sysadmin/js',
          'kv_sysadmin/_source': 'amber-projects/kv_sysadmin/st'
          ,'com_example_hello': 'amber-projects/hello/js'
          ,'com_example_hello/_source': 'amber-projects/hello/st'
        }});
Following:
        // Load own packages
        require(['kv_sysadmin/Utils'
          ,'com_example_hello/KnockoutV3'
        ], function () {

Works fine.