Make `newclass <STR>` and `newclass <PMC>` consistent

[Austin_Hastings]

(I have marked this "bug" because a reading of the code suggests the behaviors are already in agreement. But see the attached file to show otherwise.)

Creating a class via newclass <STR>

$P0 = newclass 'Dog'

does not add methods from the namespace. While creating the same class via newclass <PMC>

.local pmc class_info
class_info = new 'Hash'

class_info['name'] = 'Dog'
$P0 = newclass class_info

will cause the namespace to be scanned for methods (if the PMC passes a series of validations).

In fact, the documentation for newclass states that it accepts an optional PMC with init info: newclass <STR>, <PMC>, but this is unsupported in the ops. I believe the current behavior is acceptable, but the <STR> and <PMC> versions should behave the same w.r.t. harvesting methods from the namespace. (Alternatively, if there is to be a variant that does not scan for methods, it should be the <PMC> version under the control of a configuration setting in the PMC.)

[Austin_Hastings]

Shows inconsistent behavior between newclass <STR> and <PMC>

[Austin_Hastings]

The cause here was a misunderstanding on my part of acceptable name formats. The "Foo;Bar;Dog" used when dumping names is not valid for creating new ones. (?!)

Converting to [ 'Foo' ; 'Bar' ; 'Dog' ] produces a Class-Already-Registered error, and converting 'Dog' to 'Cat' (with a duplicated namespace) produces correct behavior.

Closed.

Thanks to Jonathan, NotFound on #parrot.