text:
Dsurround and Future Pack compatibility issue

Mod Version:
3.6.1.0
Forge Version:
forge-14.23.5.2854
Link to client log:
Latest log attached as file, log too big for pastebin and hastebin
latest.log
Link to crash log:
Crash log https://pastebin.com/YAcMYNSE
Description:
Description of the problem.  In the case of crashes, it is good to know things like the following:

Did you just add the mod to a pack? No, this was already in the pack. I believe it may be compat issues with FuturePack as seen previously in #550 only reporting here first as the log points to dsurround
Did it just start crashing, or has it always crashed? No
Did you update any other mods in your pack and it started crashing?  Added Future Pack
If updating multiple mods did you update one by one or all at once?  N/A
Is the modpack you are using available online somewhere?  Custom modpack i'm developing to release on CurseForge

Crashes in the final initialisation stages just before the main menu would be shown

Try 3.6.1.1.  You will need to install MixinBootstrap as well (current version - the mod works on multiple different versions of MC).

Thanks for the response, I can only find a 3.6.2.0 beta version. Is this the one you meant?

I tried with 3.6.2.0 and the crash still happens
crash-2020-10-25_19.29.55-client.txt
latest.log

Is this the first time adding DS to your pack?  It's crashing because DS cannot find one of its own classes, meaning that the mod didn't load all the way, or something prevented some of its classes from loading.  Can you disable VanillaFix to see what the callstack is without it's involvement?

No, DS has been in the pack since day 1. Here are the logs with VanillaFix disabled. Let me know if you need anything else from me :)
latest.log
crash-2020-10-26_08.34.40-client.txt

So what changed from the time DS was working until it wasn't.  Did you just upgrade DS, or were other mods added/removed/upgraded as well?

The only change is the addition of future pack. If I disable it, DS loads.
Like I said earlier,  reporting here first due to the logs pointing your way.  It could well be future packs fault

Found this gem: https://github.com/MinecraftForge/MinecraftForge/issues/6719.  Its for 1.15.x, but I believe it is in 1.12.x as well.

Interesting. So this could be an inherent Forge issue. Does that mean currently there is no way to solve this and I'll need to choose between future pack and DS?
If that's the case I'll have to live without future pack as DS is too good to exclude

It looks to be a Forge issue.  And unfortunately it would require a choice on your part.  I will keep mulling things over to see if I can figure a way around this issue.

No worries, thank you for taking the time to look at this. Its just weird it always seems to be DS and Future Pack that cause it haha

authors: KangyKSLG OreCruncher

repo: OreCruncher/DynamicSurroundings


text:
有道云笔记执行报错

使用短信验证码登录获取cookie，执行报错

可能没绑定手机号？

@weiguangchao 尝试换登录方式并重新抓取 cookie

source: gharchive/issue

authors: Oreomeow weiguangchao

repo: OreosLab/checkinpanel

license: MIT

license_type: permissive

license_source: github-api


text:
fix problem with links in PR with organisation

Same issue like here

We need to write some Postman tests asap.

@OrkoHunter postman interesting idea, but maybe better to start from unit tests?

Yeah cool. Although the library is still in danger unless the API routines are tested.

source: gharchive/pull-request

authors: OrkoHunter chinskiy

license: mit

license_source: bigquery


text:
Failing with Orleans 2.0 rc1

So I updated a .net core project using orleans 2.0 beta3 to rc1. After that my tests are failing as
Test Name:	should_add_item
Test FullName:	OrleansSilo.Tests.TodoGrainImplTests.should_add_item
Test Source:	D:\code\OrleansK8S\src\OrleansSilo.Tests\TodoGrainImplTests.cs : line 24
Test Outcome:	Failed
Test Duration:	0:00:03.267

Result StackTrace:
at Orleans.TestKit.TestKitSilo..ctor()
   at OrleansSilo.Tests.TodoGrainImplTests.BeforeEach() in D:\code\OrleansK8S\src\OrleansSilo.Tests\TodoGrainImplTests.cs:line 18
Result Message:	System.TypeLoadException : Method 'GetServices' in type 'Orleans.TestKit.Streams.TestStreamProviderManager' from assembly 'OrleansTestKit, Version=2.0.0.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.

My BeforeEach looks like this:
    [TestFixture]
    public class TodoGrainImplTests
    {
        private ToDoGrainImpl grain;
        private TestKitSilo silo;
        [SetUp]
        public void BeforeEach() {
            silo = new TestKitSilo();
            grain = silo.CreateGrain<ToDoGrainImpl>("RANDOM");
        }

        [Test]
        public async Task should_add_item()
        {
            var todo = GetTodo();
            await grain.AddTodo(todo);

            var items = await grain.GetAll();
            Assert.IsTrue(items.Any(it => it.Id == todo.Id));
        }

@raghur it looks as though one or more of your assemblies (eg, Orleans.TestKit) were built against an older version of Orleans.

Yes, I should get a version using the RC out later this week.

I upgrade references to RC1 #38

Orleans TestKit Nuget is now available for 2.0-RC2

authors: AdamWyzgol ReubenBond dsarfati raghur

repo: OrleansContrib/OrleansTestKit


text:
train the detection model on a subset of the coco classes

Hi,
I'm trying to train model with only 2 class(person and background).
I know that I should modify train.prototxt and test.prototxt.
I trace "models/coco/ResNet-101/rfcn_end2end/train_agnostic.prototxt",and discover that the param cls_num of layer rfcn_bbox is 8 not 21.
layer {
  name: 'input-data'
  type: 'Python'
  top: 'data'
  top: 'im_info'
  top: 'gt_boxes'
  python_param {
    module: 'roi_data_layer.layer'
    layer: 'RoIDataLayer'
    param_str: "'num_classes': 21"  --->num_classes=21
  }
}

layer {
    bottom: "conv_new_1"
    top: "rfcn_cls"
    name: "rfcn_cls"
    type: "Convolution"
    convolution_param {
        num_output: 1029 #21*(7^2) cls_num*(score_maps_size^2) --->cls_num=21
        kernel_size: 1
        pad: 0
        weight_filler {
            type: "gaussian"
            std: 0.01
        }
        bias_filler {
            type: "constant"
            value: 0
        }
    }
    param {
        lr_mult: 1.0
    }
    param {
        lr_mult: 2.0
    }
}

layer {
    bottom: "conv_new_1"
    top: "rfcn_bbox"
    name: "rfcn_bbox"
    type: "Convolution"
    convolution_param {
        num_output: 392 #8*(7^2) cls_num*(score_maps_size^2) ---> cls_num=8

this part in "pascal_voc/ResNet-101/rfcn_end2end/class-aware/train_ohem.prototxt" is "num_output: 4116 #8*(7^2) cls_num*(score_maps_size^2)"
In issue "cls_num in prototxt is not same", liyi14 says it is a typo in that case.
Is it also a typo in this case?
In "daijifeng001/R-FCN/models/rfcn_prototxts/ResNet-50L_res3a/train_val.prototxt", this part is also "num_output: 392 #8*(7^2) cls_num*(score_maps_size^2)".

        kernel_size: 1
        pad: 0
        weight_filler {
            type: "gaussian"
            std: 0.01
        }
        bias_filler {
            type: "constant"
            value: 0
        }
    }
    param {
        lr_mult: 1.0
    }
    param {
        lr_mult: 2.0
    }
}

Is there any other line I need to modify?
Thanks for the help!

Oops, I forgot to see the issues that was be closed.
https://github.com/Orpine/py-R-FCN/issues/9
https://github.com/Orpine/py-R-FCN/issues/3
https://github.com/Orpine/py-R-FCN/issues/44
The question I asked has been solved.

repo: Orpine/py-R-FCN


text:
on_stderr does not mean error

Job can complete successfully even if printing out on stderr

This should be fixed by #64


text:
Add new student

Здравствуйте,
Пожалуйста, добавьте в группу. Изначально использовал ошибочный репозиторий.
Спасибо

Здравствуйте!)
Репозитории созданы, приглашение у вас в почте
Постарайтесь принять его как можно быстрее =)

authors: aasdhajkshd mrgreyves


text:
Removed all references to text_code

(or attempted to). Should solve #56 (assuming tests and such pass)

The code quality failure is because we need to merge in https://github.com/Oufattole/meds-torch/pull/52
@Oufattole can you approve and merge that?

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Please upload report for BASE (55_dataset_cleanup@360f02f). Learn more about missing BASE report.

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@                  Coverage Diff                  @@
##             55_dataset_cleanup      #57   +/-   ##
=====================================================
  Coverage                      ?   64.17%
=====================================================
  Files                         ?       10
  Lines                         ?      723
  Branches                      ?        0
=====================================================
  Hits                          ?      464
  Misses                        ?      259
  Partials                      ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: codecov-commenter mmcdermott

repo: Oufattole/meds-torch


text:
iOS simulator doesn't detect InternetStatus.connected after disconnection

Hi,
On the iOS Simulator the package doesn't detect reconnection after disconnection
i have to reload and invalidate the view so a new status : InternetStatus.connected is received

@mohadel92 provide the following details for me to test it.

Minimal Reproducible Code Sample
Package Version you are using
Output of flutter doctor -v
Screen recording of the issue

Closing due to no activity.


text:
util: add 0x16 example lines to unit tests

Closes #158

@valarnin Since you reviewed the broader refactoring on the example log lines, would you mind giving this a review too?

repo: OverlayPlugin/cactbot


text:
To Twigil or Not To Twigil

In Corinna, you can write this:
class Point {
    has ($x, $y) :param;

    method move ($dx, $dy) {
        $x += $dx;
        $y += $dy;
    }
}

But instead of moving the point via differences, what if you wanted to just pass the new x and y values?
method move ($x,$y) {
    ...
}

You can't do that because the local variables $x and $y hide the instance variables. In Java, you could do this:
public void move (double x, double y) {
    this.x = x;
    this.y = y;

Corinna's semantics are sufficiently different from Java's that we don't have this option. What are our options?

Inner-scope lexical variables hide instance variables (this is pretty much what Perl does now)
Adopt (allow, require?) some kind of "twigil" for instance variables
Something else I haven't thought of?

The twigils might look like this:
class Point {
    has ($.x, $.y) :param;

    method move ($x, $y) {
        $.x = $x;
        $.y = $y;
    }
}

While I kind of like like that and it makes it immediately clear that this isn't just a normal local variable, nonetheless, introducing even more punctuation could increase Perl's reputation for line noise. Given that I don't see Java devs complaining too often about confusing local and instance variables, I'm not sure if we really have an issue, other than the fact that when our lexical variables hide instance variables, there's not much we can do to work around this other than providing a :writer:
class Point {
    has ($x, $y) :param :writer;

    method move ($x, $y) {
        $self->x($x);
        $self->y($y);
    }
}

Vote! Should we have twigils or not?

You DEFINITELY should have separate namespaces for slots and parameters.  It is normal and good that one should be able to use the same unqualified names for corresponding slots and parameters.  Twigils would seem to fit the bill tersely.  That being said, I would follow the Raku example and make it $! like $!x since they are private rather than going $. which is like public.

I believe the best solution aesthetically is something where if you have multiple objects of the current class a method of that class can access each of their members with the same verbosity.  So if you have say a $self and an $other where the first is an implicit method argument and the second is an explicit argument then you can, say go $self::x and $other::x or something.  If you had an actual twigil $.x or whatever for $self, what would you say for $other?  So I support whatever gives balance between the 2 objects.

introducing even more punctuation could increase Perl's reputation for line noise.

TBH, I don't think it's productive to worry about Perl's reputation. It's unlikely it will ever change, especially because of such a small change. Memes rarely go away.

I believe the best solution aesthetically is something where if you have multiple objects of the current class a method of that class can access each of their members with the same verbosity. So if you have say a $self and an $other where the first is an implicit method argument and the second is an explicit argument then you can, say go $self::x and $other::x or something. If you had an actual twigil $.x or whatever for $self, what would you say for $other? So I support whatever gives balance between the 2 objects.

The problem with any syntax that includes the instance variable is that they are generally already valid syntax that isn't reasonable to overload. $self::x means the global variable $x in the package self. $self:x could be part of a ternary. $self.x is concatenating $self with the return from calling the sub x. Syntax like $:x or $.x on its own does not have this problem. I can't think of any syntax that actually works for this that isn't extremely hateful.
There hasn't been any discussion about providing access to members in other objects, even of the same class. All current and potential future plans have revolved around using methods for that, possibly with a trust or protection model.

I believe the best solution aesthetically is something where if you have multiple objects of the current class a method of that class can access each of their members with the same verbosity. So if you have say a $self and an $other where the first is an implicit method argument and the second is an explicit argument then you can, say go $self::x and $other::x or something. If you had an actual twigil $.x or whatever for $self, what would you say for $other? So I support whatever gives balance between the 2 objects.

The problem with any syntax that includes the instance variable is that they are generally already valid syntax that isn't reasonable to overload. $self::x means the global variable $x in the package self. $self:x could be part of a ternary. $self.x is concatenating $self with the return from calling the sub x. Syntax like $:x or $.x on its own does not have this problem. I can't think of any syntax that actually works for this that isn't extremely hateful.
There hasn't been any discussion about providing access to members in other objects, even of the same class. All current and potential future plans have revolved around using methods for that, possibly with a trust or protection model.

To be clear, I'm not proposing any specific syntax like the :: or whatever, I only used that to illustrate the balance thing by using the same syntax for self/other.
I also want to be clear that I actually consider it a misfeature of common OO systems that there even is a conceptual difference between "self" and "other".  I much prefer the conception in functional languages that you just have routines and they have parameters and you treat all the parameters the same.
Especially when you're talking about a routine that has multiple parameters of the same type and all the parameters are that type, such as comparison or addition or whatever, so you have foo($x,$y) where $x and $y are objects, you should be able to use the same syntax on both parameters to access their slots.
With classes the normal thing that everyone expects is that when a class declares a "private" slot or method, that all methods of that same class can access them for every object of that class on equal terms, and it makes no difference whether in a call $x->foo($y) whether it is the $x or $y object of that class.
Methods inside a class are NOT the same as methods of any other class.
Today is the first time I heard any notion of Corinna being designed to treat private slots differently as to whether class Foo can see them for $x and not $y.  I hope that's not the case, it seems counter to any good design and seems unjustified.

I suggest a solution could be some unused variant of ->.  So normal -> is used for regular accessors generated by :reader or :writer etc like is normal for Perl.  And then something like I don't know ->> or -!> pick something is how a class references its own private slots on any object whether $self or $other.  So eg $self->>x and $other ->>y.  This is balanced, there is no twigil, and an appropriate choice doesn't conflict with anything that exists now.

@duncand A difference between twigils and your proposed ->>, is that twigils will still interpolate nicely into strings.

A couple of ideas:

In the same way my and our exist, another keyword could be used to get an object instance variable into the scope. Maybe you can even reuse has for that:

class Foo {
  has $x;
  method ($x) {
    has $x = $x;
    # now $x refers to the instance variable
  }
}

I am not sure this bring-the-slot-into-scope behavior would be too user friendly but it removes the need for a new syntax and it is consistent when how scope is already managed.

Twigils but surrounded by curly brackets:

class Foo {
  has $x;
  method ($x) {
    ${.x} = $x;
  }
}

Using that in current perl syntax results in an error, so it doesn't conflict with any currently valid syntax.

@salva the has $x = $x is a very interesting idea, but I think it doesn't read well. However, there's been discussion of using slot or attr instead of has, though it's not been settled. However, if we go with slot, we get this:
class Point {
    slot ($x, $y) :param;

    method move ($x, $y) {
        slot $x = $x;
        slot $y = $y;
    }
}

That would neatly sidestep the issue, at the expense of overloading the meaning of the slot keyword.

Leaving aside the twigil issue, why not have a move method that behaves in a relative manner, and a move_to method that does an absolute move?

@talexb Those are both reasonable, but I needed to have an example which showed the inadvertent data hiding.

https://docs.raku.org/language/variables is useful for 2 reasons:

it clearly defines what a twigil is
it shows that you're heading towards perl 6/raku, which for your intents I think is a huge mistake

If you want this to be successful (and I want to see it successful myself), it needs to tend towards Perl5. This is just what the last 20 years has shown us. Otherwise, you're just risking the reimplementation (or vulnerable to the accusation) of Perl 6/Raku.

Leaving aside the twigil issue, why not have a move method that behaves in a relative manner, and a move_to method that does an absolute move?

@talexb I believe it's not about solving the presented code. If it were, one could simply use a different name and avoid the lexical trap altogether:
class Point {
    has ($x, $y) :param;

    method move ($new_x, $new_y) {
        $x = $new_x;
        $y = $new_y;
    }
}

I think @Ovid is just trying to expose the caveat that "local variables named like instance variables will not work". Even more so, they are an issue that will bite people, specially newcomers, because the '"my" variable $x masks earlier declaration in same scope' warning only happens when you actually declare them in the same scope, not when we declare a variable with the same name on an inner scope:
$ perl -WE 'my $x; my $x;'
"my" variable $x masks earlier declaration in same scope at -e line 1.

$ perl -WE 'my $x; { my $x; }'
(no warnings)

Because this is already an issue with Perl, I would NOT add twigils or any other form of "magic" workaround unless it's something pervasive throughout the language (which may never happen), or at the very least under regular signatures.
perl -Mfeature=signatures -WE 'my $x = 1; sub x ($x) { $x = $x } x(2); say $x'
The signatures feature is experimental at -e line 1.
1

So, until it is fixed in Perl (fsvo "fixed"), I wouldn't try to change this behavior in Corinna at all. I'd add it to the "CAVEATS" section of the docs and move on.
Which is to say I agree with @Ovid's final comment that "(...)'m not sure if we really have an issue, other than the fact that when our lexical variables hide instance variables, there's not much we can do to work around this other than providing a :writer:" (or using another name for either variable, or making the instance variables private and providing getters, or ...)

@Ovid @salva By trying to avoid linenoise with twigils, you fall into another big problem: extra code for simple ops. Moreover, in the following example it's really weird to have lexical parameters being instantly overwritten with slots...
class Point {
    slot ($x, $y) :param;

    method move ($x, $y) {
        slot $x = $x;
        slot $y = $y;
    }
}

Instead you could consider doing this:
class Point {
    slot ($x, $y) :param;

    method move (slot $x, slot $y) {
    }
}

Or, depending on what considered corinnish way of doing things:
class Point {
    slot ($x, $y) :param;

    method move ($x :slot, $y :slot) {
    }
}

The original idea about "lexical slots" could still be used though for when slots might be needed deeper inside the code:
class Point {
    slot ($x, $y) :param;

    method move ($x, $y) {
        if ($self.some_condition($x, $y)) {
            slot $x = $x;
            slot $y = $y;
            ...
        }
        else {
             die "The coords are bad, really bad!";
        }
    }
}

@Grinnz ~ as an attempt to address your "confused" emoticon, I'd like to just simply put it this way. If Cor can't be discussed or implemented without sticking to familiar Perl 5 concepts, then this is a red flag and might indicate the need to seek a return to the ground state; that being things and stuff that will be familiar to perl 5 programmers - which Cor needs to keep as a potential set of users. Deviating from that is where I've seen all efforts fail - Perl 6 just being the most epic example - in terms of a natural progression of Perl 5 ( don't think this can be disputed ).

None of this has anything to do with Raku/Perl 6. Just because a term has been used by Raku does not mean it owns the term.

@haarg you're grossly missing my point, but I digress

Why not something like the following to access slots:
class Point {
    slot ($x, $y) :param;

    method move ($x, $y) {
        if ($self->some_condition($x, $y)) {
            $self{ x } = $x;
            $self{ y } = $y;
            ...
        }
        else {
             die "The coords are bad, really bad!";
        }
    }
}

gives a differentiation between methods accessed using -> and variables accessed using {...}, and kind of makes sense given existing perl ideas, basically making %self be the backend magic for accessing slots. Coming from a newbie perspective as well, it'l just look like $self is how you get to the classes items in general, making it easier to teach basic concepts of hash vs hashref later (assuming someone comes into perl and dives straight for Cor based code anyway)

Minor aside for the example I just gave, it makes the following possible:
class Point {
  slot ($x, $y) :param;

  method move ($x, $y) {
    $self{ x } = $x;
    $self{ y } = $y;
  }

  # override the get for x for some reason
  method x () {
    return $self{ x } / 10;
  }
}

As I assume you'd use a Point class as such:
my $point = new Point;
$point->move(5,5);
say $point->x; # 0.5

I don't think extended sigils are needed, because a naming custom -- such as is currently done with leading underscores in a lot of packages -- would work just fine. Why not follow that convention and always write
has ($_x, $_y) :param;
very simple very easy no problem any more.

I'm not seeing that the override-outer-scopes thing is really a widespread problem.
In those rare cases where it is a problem, using  has($_x) :name(x), or alternatively method ( :x($new_x), :y($new_y) )  , would avoid it.

I agree with @davidnicol, specially since :param already removes leading underscores.
That said, this is yet another workaround. If the developer forgets about this and uses the same name, the "masks earlier declaration" warning will not show up and a hard to detect(?) bug will happen. But (again), since this already happens with signatures and pretty much any other inner block in perl, I think it should be added to a don't-do-this caveat section and that's it. Unless it's something worth changing everywhere.

I don't think extended sigils are needed, because a naming custom -- such as is currently done with leading underscores in a lot of packages -- would work just fine. Why not follow that convention and always write
has ($_x, $_y) :param;
very simple very easy no problem any more.

Since it's a core feature we're designing right now, it seems like a mistake to design it to require a special workaround when we can just, not do that.

Could the parser simply throw an error if a lexical variable has the same name as a slot?  Maybe not Perlish (taking away a footgun) but it resolves the problem without new syntax.

I don't think extended sigils are needed, because a naming custom -- such as is currently done with leading underscores in a lot of packages -- would work just fine. Why not follow that convention and always write
has ($_x, $_y) :param;
very simple very easy no problem any more.

I consider that a very dirty kludge.  The only clean solution is that there are separate namespaces for slots from other things so people can use the same nice names for both without conflict.

I agree with @davidnicol, specially since :param already removes leading underscores.

Object::Pad does this, because Object::Pad is a playground to experiment with these ideas. A core implementation will definitely not have any special handling for slots beginning with underscores.

Object::Pad does this, because Object::Pad is a playground to experiment with these ideas. A core implementation will definitely not have any special handling for slots beginning with underscores.

Infact moreover, I put the underscore handling in precisely because of a lack of ability to do twigils there. If we had twigils then that wouldn't be required, as things like
has $:name :reader;

would already create a reader method named name, and not :name.

This doc section may also be relevant
https://metacpan.org/pod/Object::Pad#Slot-Names

I feel we're overly focusing on the ambiguity between slots and method arguments with the same names. Twigils fix that problem, which is wonderful, but that's not the main reason why I want them in Corinna.
To me, the biggest benefit of twigils is the ability to tell variables from slots at a glance.  Slots aren't normal variables, they're special, so it makes sense to make them look different. It's also very perlish. After all, concise explicitness is a distinguishing feature of Perl, sigils and the separation of numeric/stringy operators are good examples of that.

I feel we're overly focusing on the ambiguity between slots and method arguments with the same names. Twigils fix that problem, which is wonderful, but that's not the main reason why I want them in Corinna.
To me, the biggest benefit of twigils is the ability to tell variables from slots at a glance. Slots aren't normal variables, they're special, so it makes sense to make them look different. It's also very perlish. After all, concise explicitness is a distinguishing feature of Perl, sigils and the separation of numeric/stringy operators are good examples of that.

Twigils can be useful for a common shorthand but the more general solution needs to work for both $self and $other objects of the current class to directly reference slots that have no :reader or :writer defined.

So I suggest that a general form could be like $self!x and $other!y and then $!x would be a short-hand for the first and the short-hand wouldn't exist for the second.

The general form would need to take any arbitrary expression and combine it with a slot lookup, so <any expression here> !x for example.  Since slots are always private we know at compile/parse time that the !x or whatever is a slot for the current class and so it expects that the expression to its left would evaluate to an object of the current class, though in the general case that would possibly fail at runtime if it isn't actually an object of the current class when that is evaluated.

What about this?
my $x = 12;
{
    my $x = 'hello world';

    say "inner x = $x";
    say "outer x = $.x";
}

We don't need that why would we need this abomination for Cor? That idea and need is already confusing to me - why does scope work different in methods? Just don't name variables in your method the same as slots in the object if that method needs to access the object slot.
I'm excited about Cor because it "looks and feels" like Perl, something other systems like Moose or Mojo do not (to me). Adding this completely not obvious twigils just make the code harder to read for no real gain (IMHO) - but I'm just a hobbyist.

Problems become 3 parts:

should prevent arguments hiding attributes in method?
should have some specific syntax to call attribute in method?
this syntax is twigil?

I believe the best way to design this is to do something that directly mirrors the current blessed hashref approach, which is that you ALWAYS reference a slot in terms of a subscript of an object of the type.
The blessed hash way:
  $self->{x}
  $other->{y}
  (any appropriate value expression)->{z}

The Corinna way:
  $self->!x
  $other->!y
  (any appropriate value expression)->!z

Or something like that.
When I say that slots should have their own namespace, the above is what I really mean, each object such as $self or $other IS the namespace for the slots, and all other kinds of Perl variables continue to scope/behave as they did before.
We really don't need twigils, but we do need the "->" alternative to mean its a slot direct access, whereas plain -> would apply to a defined :reader etc if and only if they exist.

Another syntax that can be repurposed for accessing the slots is the quote (currently an alias for ::):
class Point {
    has ($x, $y) :param;

    method foo ($x) {
      $self'x = $x;
    }

    method bar($other) {
      $x += $other'x;
      $y += $other'y;
    }
}

Though, I am not sure it is going to be completely unambiguous when used in more complex code structures. For instance:
$x->{foo}'bar;

String interpolation can be an issue too: "hello '$name'ssss"

Another syntax that can be repurposed for accessing the slots is the quote (currently an alias for ::):

I find it distasteful to use string delimiting characters for any purpose besides string delimiting, so no use of double quotes, single quotes, or backpacks for anything except delimiting strings.

Having given this further thought, I concede that at the moment its hard to think of good examples where both of the following are true at the same time for a given class Foo:

A method of Foo wants to access a slot S for any other object of the Foo class besides the $self object.

Slot S doesn't have any :reader or :writer or other custom public accessor method because it isn't okay for non-Foo classes to see it.

Therefore with respect to the MVP of Corinna I withdraw my objection for the direct access mechanism to slots of Foo being only available for the $self object.
For the MVP I consider it a reasonable compromise to have to declare a public :reader etc method for situations where a method needs to access slots of $other in addition to $self.

@duncand,

A method of Foo wants to access a slot S for any other object of the Foo class besides the $self object.

It is pretty common to have functions that take two arguments of the same class. For instance, any class implementing mathematical objects for which some kind of algebra exits  (vectors, quaternions, sets, etc.).
For instance, a class implementing sets providing an intersection method that takes $self and $other as arguments. In order to calculate the intersection efficiently you may like to access the internal representation of both objects without being restricted to accessing $other just through its public interface.

A few other points of note, from my docs on this:
Compare in classical perl OO, with syntax highlighting in editors/etc the $self->{...} variables are easy to see because of highlighting.
A simple use of Object::Pad syntax as it currently stands makes them much harder to see because they look identical to lexicals. The use of a unique twigil, such as $:name would make these stand out more - both in plain syntax to a human reader, and also make simple syntax highlighters able to much easier call them out as looking different.
(see also the screenshots in my doc:
https://docs.google.com/document/d/1d62U2Z3w8zUnzg2QVxuGN6gtCoKATuiW1SCCSVRVIgc/edit#heading=h.a41lkp4lj35 - I couldn't work out how to embed an image here)

Additionally, "unbound methods" with syntactically unambiguous slot accesses inside could solve the question of how a MOP API can add method bodies which refer to such slots. An :unbound attribute could permit the parser to compile a prototype method body unbound to a particular class that can use any slot name, which only becomes checked (and presumably resolved into representation indices) at the time it is bound into a class: Hypothetically allowing such code as:
package NotAClass;

sub import {
  my $class = Object::Pad::MOP->create_class( "Ball" );

  $class->create_slot( '$:colour' );

  $class->create_method( paint => method :unbound {
    say "Will now paint $self in colour $:colour";
  } );
}

as without this ability it becomes difficult to write method bodies.

@leonerd,
I think it is reasonable to not have syntax sugar for cases where you are already using the MOP.
IMO, requiring a more convoluted way for accessing slots could be acceptable. For instance:
$class->create_method( paint => sub ($self) {
    my \$colour = $class->get_ref_to_instance_slot($self, "colour");
    say "Will now paint $self in colour $colour";
  } );

That means the method you created would be significantly slower, which would in most cases mean nobody would use the MOP for this.

That means the method you created would be significantly slower, which would in most cases mean nobody would use the MOP for this.

If you are serious about the MOP, whatever syntax sugar you use would result at the end into a call like the one above. Every time an slot is referenced from a method you have to perform a lookup (or do it when entering the method and cache it as it is done in the code above).
At most, you could use a faster lookup method for the common case (i.e. default storage), but then, you could also use that shortcut in the code above.

People aren't "serious about the MOP", they are serious about solving their task in a way that works. The task of this design is to make the way that works natural to use and huffman coded.

@duncand,

A method of Foo wants to access a slot S for any other object of the Foo class besides the $self object.

It is pretty common to have functions that take two arguments of the same class. For instance, any class implementing mathematical objects for which some kind of algebra exits (vectors, quaternions, sets, etc.).
For instance, a class implementing sets providing an intersection method that takes $self and $other as arguments. In order to calculate the intersection efficiently you may like to access the internal representation of both objects without being restricted to accessing $other just through its public interface.

@salva Yes, I am keenly aware of such common cases to use $self plus $other, the math-like things are what I had in mind.
But my first sentence both of the following are true at the same time is the key here, and you didn't counter that.
I figure that in such objects it would be normal that you'd want any class to be able to see the same slots, say to read out the elements of the vectors etc, and so sufficient public accessors would be provided to read them such as with :reader.
Of course I would still rather have what I argued for originally, direct access to all objects, but I realized for an MVP the public accessors should be sufficient, so I won't push it so much.

@duncand,

But my first sentence both of the following are true at the same time is the key here, and you didn't counter that.

Yes, I was thinking about that too.
You have an internal representation for your objects that you would like to access when implementing some algorithm combining two objects of the same class.
For instance:

A class representing a tree or a queue and a method to merge two of them. In order to do that efficiently you usually need access to the internal representation.
A matrix or tensor class where data is stored packed as NVs plus the dimensions and some internal house keeping values (i.e. offsets and stripe sizes). You don't want to make that internal data public, but you need it in order to implement an add operator efficiently.

@duncand,

But my first sentence both of the following are true at the same time is the key here, and you didn't counter that.

Yes, I was thinking about that too.
You have an internal representation for your objects that you would like to access when implementing some algorithm combining two objects of the same class.
For instance:

A class representing a tree or a queue and a method to merge two of them. In order to do that efficiently you usually need access to the internal representation.
A matrix or tensor class where data is stored packed as NVs plus the dimensions and some internal house keeping values (i.e. offsets and stripe sizes). You don't want to make that internal data public, but you need it in order to implement an add operator efficiently.

I have 2 main points to answer this:

To properly solve the general version of this we need something like Raku's "trusts" because in the general case there are MULTIPLE classes involved in the internal representation of a data structure and any one of those classes, or additional classes, should be able to access their members directly.  An example I've mentioned in the past is a graph data structure including separate Node and Side classes plus a class representing an entire Graph.  Simply being able to see $self and $other slots isn't enough, its only a half-measure.

A workaround for the MVP I would settle for which I might have to do anyway for that multi-class graph example even if private works normally, but can also work if you don't get $other, is to declare "public" accessor methods which are named such that it clearly documents they aren't part of the normal public API and are just part of the internal implementation, for example the method could be named "_internal__foo" or such.  Assuming the internal properties in question are reference types these can return direct references to them, and then the caller can work with them as if they had direct access to the slots.

To properly solve the general version of this we need something like Raku's ...

... as predicted  xD

To properly solve the general version of this we need something like Raku's ...

... as predicted xD

@oodler577 So what?  Its a good idea that JUST HAPPENED to be in Raku first.
I could have said C# internal (Java's package-private is a stupider analogy of that) which are also the same idea but Perl doesn't have the concept of packages that they have and so naming individual classes you trust is what Perl CAN do.
@oodler577 Perhaps you would like me to describe the desired feature from scratch without pointing to an illustrative example of where it was done before?

For what it's worth, I'd like to retract my suggestion of using (or,
implicitly suggested, enforcing) a leading underscore naming convention,
and replace that with a more compatible convention of always giving slots
L-value methods.
I often do that in my perl classes, so if that becomes how Corinna does it,
Corinna could become a set of standards that can be complied with -- one
could duck-type any old class into Corinna compatibility -- instead of a
hard interoperability boundary, that there will be a penalty for
interoperation between Corinna and non-Corinna types.
Hashref object implemention-specific slot access:   $obj->{field1} = 27;
Implementation-agnostic method-based slot access:  $object->field1 = 27;
This is what I'm talking about, l-value slot accessors:
set up the field1 method in an array-based class:
sub field1 :lvalue { $_[0]->[5] } # assuming the index of field1 is 5

set up the field1 method in a hash-based class:
sub field1 :lvalue { $_[0]->{field1} } # duh

set up the field1 method in an inside-out object (as I understand them,
which is barely, and possibly wrong):
sub field1 :lvalue { no strict refs; ${"${$_[0]}::field1"} }  # object

is a reference to a scalar containing a unique package name, it isn't clear
to me what is gained by this approach
With L-value slot-accessor methods, the code that uses the class doesn't
need to know about the object's implementation to access the slots.
So do it that way.
Hmm -- I wonder how the proposed "defer" stuff interacts with :lvalue
routines. Can it be used to create on-modification magic?
On Thu, Aug 12, 2021 at 5:13 PM Graham Knop @.***>
wrote:

I agree with @davidnicol https://github.com/davidnicol, specially since
:param already removes leading underscores.
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

To properly solve the general version of this we need something like Raku's ...

... as predicted xD

Please refrain from cluttering up the discussion unless you have substantive feedback on an idea rather than a triviality.

@davidnicol For some reason "quote reply" doesn't work on your post, it just smooshes everything into 1 paragraph.  Anyway...
In principle the lvalue thing you proposed sounds like what I was trying to propose.
However, this is an area I'm not so experienced in, so I'm unclear if these automatically generated lvalue methods would conflict or not with :reader or :writer generated ones.  For example, would invoking $self->x and $self->x() call 2 different methods or the same one?
We still want to have the thing where slot access is private to its own class by default and you only get access from other classes, whether by lvalue or otherwise, by a separate explicit declaration like :reader.

@duncand,

1. To properly solve the general version of this we need something like Raku's "trusts" because in the general case there are MULTIPLE classes involved in the internal representation of a data structure and any one of those classes, or additional classes, should be able to access their members directly.  An example I've mentioned in the past is a graph data structure including separate Node and Side classes plus a class representing an entire Graph.  Simply being able to see $self and $other slots isn't enough, its only a half-measure.

Is this something akin to C++'s friend designation?

The use of a unique twigil, such as $:name would make these stand out more

why the special-case for instance slots, as opposed to our, or sub parameters, or refaliases, or lexicals imported from the parent scope?
with hashref OO, $self->{method} doesn't stand out more in typical synhi config: it's the same syntax structure as any other hashref lookup
your example is using $_ twigil syntax that'd be just as easy for synhi as the $: proposal :sweat_smile:

@duncand,

To properly solve the general version of this we need something like Raku's "trusts" because in the general case there are MULTIPLE classes involved in the internal representation of a data structure and any one of those classes, or additional classes, should be able to access their members directly.  An example I've mentioned in the past is a graph data structure including separate Node and Side classes plus a class representing an entire Graph.  Simply being able to see $self and $other slots isn't enough, its only a half-measure.

Is this something akin to C++'s friend designation?

Upon looking it up (I didn't know C++ had that) then yes it appears to be the same idea.
I'm somewhat unsure from looking at it but the C++ friend might not work in the same way.
That is, in a "more secure", situation having 2 classes X and Y, it is X that contains the declaration that it trusts Y, and then Y may see the privates of X.  In a "less secure" version, Y declares it is a friend of X and then can see the privates of X.
It is unclear whether the C++ is the second "less secure" or not, but what I'm advocating for is the former "more secure".

On Fri, Aug 13, 2021 at 3:41 PM Darren Duncan @.***>
wrote:

@davidnicol https://github.com/davidnicol For some reason "quote reply"
doesn't work on your post, it just smooshes everything into 1 paragraph.
Anyway...
In principle the lvalue thing you proposed sounds like what I was trying
to propose.
However, this is an area I'm not so experienced in, so I'm unclear if
these automatically generated lvalue methods would conflict or not with
:reader or :writer generated ones. For example, would invoking $self->x
and $self->x() call 2 different methods or the same one?

those are equivalent. I seem to have proposed something that's already
there. Which makes the answer to the original topic "We don't need twigils;
we've already got access control with reader and writer attributes. A slot
that hasn't got them can't be accessed, sorry. That's by design."
--
"Lay off that whiskey, and let that cocaine be!" -- Johnny Cash

In languages where member function parameters shadow slots (e.g. C++) it can be non-trivial to distinguish the two and can lead to subtle bugs. (See  related discussion https://stackoverflow.com/questions/10250016/should-i-use-the-same-name-for-a-member-variable-and-a-function-parameter-in-c)
I would find it useful to distinguish between the two, e.g. $!x is fine by me.  I would prefer not to replicate the current necessity to indicate that a slot belongs to $self, e.g.  $self->!x.  That just clutters the code needlessly.
Should twigils be the preferred direction, please choose one that's easy to type and easy to scan.   $!x seems easy to type (at least on American English keyboards) and easy to visually scan. $.x is harder to scan; the .  can get lost in the weeds.  Some of us don't use the fancy coloring code editors (I flip the switches on my PDP-8 and read the output on my ASR43).

I will also mention as a tangent that in Java declaring something "private" is more advisory than absolute.  You can use Java's basic introspection features to alter something's visibility flag at runtime and therefore directly access a private member that the compiler otherwise prevents.  This is a feature, it is the basis for injection frameworks to function.
What is relevant here is how that can inform Perl.  What I would expect from a "trusts" or other "private" feature provided by Corinna is that it indeed enforces these limitations under all normal circumstances.  But at the same time, there could be legitimate reasons for a new class Z to force its way into the internals of X without X ever having been aware of it, like X was aware of Y in order to name it.  This ability of Z should have friction so people recognize it as exceptional and not for normal use, but it should be possible.

It is unclear whether the C++ is the second "less secure" or not, but what I'm advocating for is the former "more secure".

In C++ you grant friendship to another class so that the other class can see your attributes.  You cannot force friendship on another class to gain access to its internals.  Friendship is not an all or nothing designation.   You can designate particular methods that are available.

It is unclear whether the C++ is the second "less secure" or not, but what I'm advocating for is the former "more secure".

In C++ you grant friendship to another class so that the other class can see your attributes. You cannot force friendship on another class to gain access to its internals. Friendship is not an all or nothing designation. You can designate particular methods that are available.

Okay thank you for the clarity, it sounds like the "more secure" way then.
Generally speaking, the way one should be looking at trusts/friend/etc is that logically you have a single class/feature/thing but you JUST HAPPEN to be using multiple classes to implement it either due to language limitations or because its a better design, but you want to treat a small set of classes as if it were 1 class in multiple parts, and so the trusts/friend/etc is how you declare the one-as-several situation.

The use of a unique twigil, such as $:name would make these stand out more

why the special-case for instance slots, as opposed to our, or sub parameters, or refaliases, or lexicals imported from the parent scope?

Instance slot lifecycle is unique to these other cases. It's not lexical or attached to a package.

with hashref OO, $self->{method} doesn't stand out more in typical synhi config: it's the same syntax structure as any other hashref lookup

Current attribute deficiencies are not an excuse to maintain such deficiencies in a new design.

your example is using $_ twigil syntax that'd be just as easy for synhi as the $: proposal 😅

Incorrect; $_ is currently a perfectly valid beginning of a variable name, and is thus not a twigil nor distinguishable from an ordinary variable by static analysis.

IMO this discussion about trusted slots from other object instances is quite a tangent and belongs in its own issue; this issue is about twigils.

IMO this discussion about trusted slots from other object instances is quite a tangent and belongs in its own issue; this issue is about twigils.

Yes and no.  If the solution we need is to access slots of both self and other object instances using a common syntax, such as is already possible with blessed hashers, and twigils by design can't do that, then it is relevant.

Given slot $:attr1, the slot name is not attr1, but $:attr1. Attempting to define any syntax for accessing slots from other instances will need to use the full $:attr1 name, as well as the full $other instance variable. Some syntax like $other!attr1 can't be used because, as stated, the slot name is not attr1. This becomes more obvious if you consider code like:
class Foo {
   slot $:attr1;
}
class Bar isa Foo {
    slot $:attr1;
}

The two slots are entirely separate, even though they are spelled the same. Syntax like $self!attr1 implies that the name is attr1, but this is not true.
Having twigils or not changes nothing about whatever syntax could be created to access "foreign instance" slot access, and so it should not be discussed here.

2. it shows that you're heading towards perl 6/raku, which for your intents I think is a huge mistake

If you want this to be successful (and I want to see it successful myself), it needs to tend towards Perl5. This is just what the last 20 years has shown us. Otherwise, you're just risking the reimplementation (or vulnerable to the accusation) of Perl 6/Raku.

I would disagree with this... It's hard to speak for the general public, but I think most people were objecting to the Perl 6 treatment of Perl 5 code as a second-class citizen and the decreased performance all around and different threading model, rather than the fancy new syntax that Perl 6 offered.

One last comment from me, since I think my signal-to-noise ratio is dropping:

why the special-case for instance slots, as opposed to our, or sub parameters, or refaliases, or lexicals imported from the parent scope?

Instance slot lifecycle is unique to these other cases. It's not lexical or attached to a package.

Technically it is lexical, as in "only valid within the area of code in which it was declared" - you can't access the slot from outside the class scope, e.g. another file or after the class block. That aside, instance slot lifecycle isn't really unique, though. Those were just a few examples - take state, for example: if lifecycle was the relevant factor, then why not apply a different twigil there? Or closures, even: if lifecycle was the gripping hand for these decisions then I'd expect to see a push for a different sigil for "this variable can be captured in callbacks" vs. "this must only be used in its own scope"...
My concern is that there seems to be a general "instance slots must be easily distinguished from everything else" push from proponents, but I haven't really seen any convincing arguments as to why that's the case.

your example is using $_ twigil syntax that'd be just as easy for synhi as the $: proposal sweat_smile

Incorrect; $_ is currently a perfectly valid beginning of a variable name, and is thus not a twigil nor distinguishable from an ordinary variable by static analysis.

I see your "incorrect" and raise you one "irrelevant" in return :smile_cat:
So as an example, we already have upper-case or prefix-case for our variables - as a convention, and not one universally applied, but it's specifically called out in perlstyle among others.
I like the way use Log::Any qw($log) gives me a simple lowercase instance without enforcing "IT IS AN IMPORTED PACKAGE VARIABLE THEREFORE MUST BE UPPERCASE" rules. That also allows one simple change to switch from use Log::Any qw($log) to has $log, with no changes to any calling code: nothing has to care! The lifecycle is not a concern for that usage, and rewriting everything to use twigils would be a matter of some disappointment to me.
We have other conventions, too - such as the underscore for private methods: synhi is free to apply additional rules on these based on those conventions, despite them not being absolute rules.
If someone has a different convention for an underscore prefix, that's fine - but if synhi has a rule for displaying those differently, then no one has to care what the conventions are, just that we wanted some visual distinction, so we have the ability to apply that visual distinction, without necessarily enforcing it.
So yes, I stand by my original comment - if you want a twigil convention, there's a clear path: use $_ and configure synhi for that. All achievable and straightforward with what we have right now, which has the advantage of offering immediate opportunities for experimentation and building some experience on which to argue for/against the various approaches.
(as to @nrdvana 's comment: you can count me as one of the people who emphatically does object (hah) specifically to the "fancy new syntax" and general extra complexity of Raku, performance can be improved and threads are nice - I'm sure its proponents enjoy the language greatly, but from a teaching aspect it seems like someone took "line noise" as a challenge, and tried to upgrade to "square noise" instead :worried: )

Do we want to support array and hash attributes (sorry, I hate the term ‚slot‘)?
In that case I‘d prefer the use of the existing twigils for those in addition to scalars.

why the special-case for instance slots, as opposed to our, or sub parameters, or refaliases, or lexicals imported from the parent scope?

Instance slot lifecycle is unique to these other cases. It's not lexical or attached to a package.

Technically it is lexical, as in "only valid within the area of code in which it was declared" - you can't access the slot from outside the class scope, e.g. another file or after the class block. That aside, instance slot lifecycle isn't really unique, though. Those were just a few examples - take state, for example: if lifecycle was the relevant factor, then why not apply a different twigil there? Or closures, even: if lifecycle was the gripping hand for these decisions then I'd expect to see a push for a different sigil for "this variable can be captured in callbacks" vs. "this must only be used in its own scope"...
My concern is that there seems to be a general "instance slots must be easily distinguished from everything else" push from proponents, but I haven't really seen any convincing arguments as to why that's the case.

In context of a limited feature where we're just concerned about access to $self slots and not $other slots, ...
I now feel that using a keyword slot similar to keywords like my/state/etc as a disambiguator is a perfectly acceptable solution.
So the normal syntax to access a slot is just $foo the same as the syntax for any normal lexical or parameter, and the slots are considered to be in the lexical scope of the class/package same as a my $foo at the package level, and therefore a parameter or lexical declared inside a routine would hide that.
In practice probably it would be relatively rare (at most half of all methods) to have parameters with the same names as slots but when this happens one can say slot $foo or (slot $foo) to disambiguate and say one is referring to the slot, and the scope of this slot keyword as used within a routine is the $foo term immediately after it.
Its not quite as terse as a twigil when used, but in the cases where there isn't shadowing the regular $foo is terser still, and the keyword is more self documenting and more self-consistent with the rest of Perl.
If we want to introduce twigils to Perl its probably best to do so more comprehensively than just for a single use case as now.

I now feel that using a keyword slot similar to keywords like my/state/etc as a disambiguator is a perfectly acceptable solution.
So the normal syntax to access a slot is just $foo the same as the syntax for any normal lexical or parameter, and the slots are considered to be in the lexical scope of the class/package same as a my $foo at the package level, and therefore a parameter or lexical declared inside a routine would hide that.
In practice probably it would be relatively rare (at most half of all methods) to have parameters with the same names as slots but when this happens one can say slot $foo or (slot $foo) to disambiguate and say one is referring to the slot, and the scope of this slot keyword as used within a routine is the $foo term immediately after it.
Its not quite as terse as a twigil when used, but in the cases where there isn't shadowing the regular $foo is terser still, and the keyword is more self documenting and more self-consistent with the rest of Perl.
If we want to introduce twigils to Perl its probably best to do so more comprehensively than just for a single use case as now.

"At most half of all methods" is relatively rare? I think there's a scale problem in this analysis.
I'm not entirely disagreeing, but the primary difference in use case is that slot variables will always be intermingled with lexical variables in every usage of them, whereas package variables are rarely used at the same time as lexicals.

"At most half of all methods" is relatively rare? I think there's a scale problem in this analysis.
I'm not entirely disagreeing, but the primary difference in use case is that slot variables will always be intermingled with lexical variables in every usage of them, whereas package variables are rarely used at the same time as lexicals.

My point is that sometimes it is better design to give parameters the exact same names as slots and be able to access both, and sometimes it is better design for the parameters to have different names.  Having shadowing and the slightly more verbose slot $foo disambiguation may create a small amount of friction encouraging the use of different names, but one can still use the same names where it is better design.  And things work without breaking the uniformity that Perl has now by introducing twigils for just this specific case.

Here's where I think we are.
Right now, one of the biggest problems we're having with Corinna is people saying "yes" or "no" without giving concrete explanations or examples of their reasoning. Fortunately in this thread, many people have been giving concrete examples and this has helped a lot.
For example, here's a slot with a twigil (twigil not yet decided):
has $:x;

method inc ($x) {
    $:x += $x;
    ...
}

Here are some of the arguments for and against them.
Pros:

You can't accidentally shadow class/instance data. (technical)
Great Huffman encoding for "this is not a regular variable" (social)
Easy to syntax highlight (technical)

Cons:

No direct parser support for twigils (technical)
Is somewhat controversial (social)
May contribute to "line-noise" complaints (social)

I can't say that I'm "for" twigils, but so far, that's two strong technical and one strong social argument for them. I see a technical argument against them (I don't know how strong it is) and two rather weak social arguments against them.
At the beginning of the discussion, I was leaning away from twigils. I kind of liked them, but I was swayed by the social arguments. Laying out the pros and cons clearly seems to show a strong benefit to using twigils.
So if you have a strong argument for or against them, if you can clearly describe it, give an example, and explain if it's a technical argument or not, I'd love to hear it (I'm quite serious about this because I'm happy to put a gun to the head of twigils, but I can't see any reason to do so at this point.)
For the following discussion, I assume that a strong technical argument beats a strong social argument.
Other solutions proposed are (not an exhaustive list) ...

Fake Slot Access
has $x;

method inc($x) {
    $self{x} += $x;
}

Pros:

Very clear as to what's going on (social)
Should feel comfortable to Perl devs (social)
Accessing $self{x} from a common method is a compile-time syntax error (technical)

Cons:

People are going to write $self->{x} and then moan when it breaks (or worse, silently fails)
Needs parser work to implement (technical, I don't know how hard this is)

I find this proposal interesting. I do wonder about this case:
common $x;

method foo(x) {
    $self{x}
    # or
    $class{x}
}

In the above, it would always make it crystal clear that $class{x} is referring to class data. I don't know enough about the technical issues, other than to say that listing the pros and cons has helped me see that this is more interesting than I thought at first.
However, there's not been enough discussion of this case for me to have a strong opinion.

Ignore the issue since shadowing is already known
has $:x;

method inc ($x) {
    # oops
}

method inc2 ($dx) {
    $x += $dx;
}

Pros:

Very easy to implement (technical)

Cons:

Harder to maintain (social)
Silent bugs can be introduced (social)
Why should Perl be one of the few OO languages which has to suffer from this? (social)
In large classes, it's often confusing trying to figure out where a variable comes from (social)

So we have a strong technical argument for and, in my opinion, two strong and two weak social arguments against.
Conclusion: we cannot ignore this issue.

Reuse the slot/has keyword
slot $x;

method inc($x) {
    slot $x += $x;
}

Pros:

Easy to implement (technical)
Easy to see what's happening (social)

Cons:

Still allows accidental shadowing (technical)
Overloads the meaning of an existing keyword (technical)
In large classes, it's often confusing trying to figure out what a variable comes from (social)

A strong technical and strong social argument in favor. Two strong technical (imho) and a weak social argument.
Conclusion: tempting, but not as strong as sigils.

Warn on shadowing
slot $x;

method inc($x) {   # warning generated here
   ...
}

Pros:

Easy to implement (technical)
Follows existing practices (social)

Cons:

Doesn't prevent variable shadowing (technical)
Developers are often conditioned to ignore warnings (social)
Too many ways for warnings to be accidentally suppressed(technical)
How do we suppress this new warning? (technical+social)

The warning suppression merits some discussion. On the #cor IRC channel, it was suggested that we simply use the existing warning mechanism. Let's look at that.
slot $x;

no warnings 'shadowing';
method inc($x) {   # warning generated here
   ...
}

# thirty more methods

We have attached the warning, but now we have thirty more methods which might have this warning, but now we no longer see those warnings. We could tell the developer "if you suppress the warning in this way, move the method to the bottom of the class", but the developer might reasonably object to that.
So let's try it again.
slot $x;

{
    no warnings 'shadowing';
    method inc($x) {   # warning generated here
       ...
    }
}

# thirty more methods

Now we've lexically scoped the warning, but it's an ugly hack, similar to the way we used to fake state variables. Further, it's more grunt work the developer has to remember. Corinna is supposed to take that away, not add to it.
The grunt work might lead a developer to rename the argument, but in a large method, that would mean finding every instance of $x and figuring out if it's the instance method $x or the argument $x and that's more of the sort of grunt work we want to avoid. Ugly!
So let's try it again.
slot $x;

method inc($x) {
    no warnings 'shadowing';
       ...
}

# thirty more methods

So that's kinda elegant, but we've put the warning after the variable doing the shadowing. I don't know of any other place in Perl we do something like this. It feels like a hack (and I don't know if it would work).
So looking at our original pros/cons liks, I see strong technical and social argument for. One strong technical argument against, and weak social and technical arguments against, but then we have the "suppression" argument. I really like the warnings idea, but I don't think it's working.

Other Ideas*
Variations of changing how signatures work.
class Point {
    slot ($x, $y) :param;

    method move (slot $x, slot $y) {
    }
}

Signatures are still experimental and I believe Dave Mitchell is still planning on doing work there. I do not believe we're at liberty to change signatures.

About cons with twigils, I don't see Is somewhat controversial (social) as an actual con like the others, rather that's more of a self-referencing argument, it is controversial because it is controversial so doesn't have a place in logical decisions based on merits.

@Ovid's summary of the options here makes me think that any option which prevents shadowing is the best choice, and the one with the twigils has the best huffman coding.
However I would also argue that if we're introducing twigils to prevent shadowing here, we should also introduce them in other places to prevent other kinds of shadowing.
For example, introduce that within a Corinna class declaration, any my $foo ALSO have sigils.
Also, conceptually, I see parameters as something that ought to have their own sigils too, because they are quite distinct in function from non-parameter lexicals.
In particular, and also compatible with the existing notion of @_ but I'm not basing it just on that, I consider the notion of the entire set of arguments to a routine being a collection-typed value, so its kind of like we have implicit $args which has a slot of its own for each parameter, and then the twigil is referencing it directly.

@duncand I do not anticipate expanding twigils to my variables because that is far outside the scope of what we're doing and I see no benefit to doing so.
Second, we cannot add twigils in signatures because, as I noted above, work on signatures is ongoing. I seriously doubt P5P would look kindly on us unilaterally changing something this fundamental to the language.
But as usual, for both of those cases, if you feel there is an argument to be made, we need:

A clear problem description (including why it's a problem)
Proposed syntax showing a solution
Explanation of why existing tools do not solve the problem

Those would probably best be done in another ticket as this one is about addressing the shadowing issue.

@duncand I do not anticipate expanding twigils to my variables because that is far outside the scope of what we're doing and I see no benefit to doing so.

When I say my I specifically mean things declared within the context of a Corinna class block that are outside a routine.
A better specific example would be Corinna class/static slots, common $x.
The original question about twigils may have implied that the decision would cover these too, but since it didn't say so explicitly, I'm saying that if twigils are used for object instance slots they should also be used for class static slots.
And possibly a different twigil from instance slots so its easier to tell them apart.
And a strong reason to do so is the cited reasons in favour of twigils, good at preventing shadowing or confusion.

@oodler577 I just want to say that negative comments regarding Raku and borrowing ideas from it are not helpful because they are not technical arguments.
Nor, in fact, are they social arguments unless you can explain why Perl borrowing from Python (core OO), C, sed, awk, and many other languages is OK while borrowing from Raku is not.
You wrote:

If you want this to be successful (and I want to see it successful myself), it needs to tend towards Perl5. This is just what the last 20 years has shown us. Otherwise, you're just risking the reimplementation (or vulnerable to the accusation) of Perl 6/Raku.

Raku has been the creation of a new language that attempted to fix all of Perl's problems and once while extending the language into heretofore unknown directions.
Corinna is:

a very limited attempt to fix one single area of Perl
almost at an RFC stage
largely implemented via Object::Pad
P5P discussions seem to imply that P5P is receptive to the idea.

Comparing Corinna to Raku is comparing a Toyota Corolla to an F-35 stealth fighter.

IMO, the biggest issue with twigils is that in a lot of cases they are already valid syntax and so, perl would have to support two syntax: the backward compatible one and the new one with twigils (activated, for instance, after use v7). That, besides a technical issue, is also a social issue as it would require the programmer to take into account which mode is active while coding.
For instance, something I do frequently is to prefix debug statements with the process id as in:
say "$$:here!";

Now, how is this going to be parsed under twigils rules, if $: is used as the slot prefix?
say($$ . ':here');  # or...
say(${$:here});

Are there other ambiguities like this one?
In summary, I think it is important to consider which specific twigil to pick for attributes and which kind of ambiguities it is going to introduce in the language in order to make a decision.

Interpolation is known to be a case where it would be ambiguous. Since interpolation of these variables would be a primary goal, one option would be to require punctuation variables to be interpolated as "${$}" or similar. There are no other ambiguous cases.

@Grinnz

This would also be a much bigger problem with the twigil $. than one which is only used in formats like $: - another solution is disabling format punctuation variables in the scope of class.

Is in fact why I originally suggested $:name rather than $.name`.
At this point I feel a lot of this discussion chain is rehashing old grounds already covered months ago.

It is, but it was correct that this issue post didn't cover this caveat that has to be dealt with for twigils to work.

Per the last few comments, it seems to me the biggest issue to resolve to adopt twigils is pick a specific syntax that is presently illegal syntax so that it wouldn't conflict with something that exists now and we can avoid the problematic option of having to use a feature flag to disambiguate.

Comparing Corinna to Raku is comparing a Toyota Corolla to an F-35 stealth fighter.

I love that one as Toyotas are as reliable as Perl 5 but comparing Raku to an F-35 is unfair! 😉

@oodler577 I just want to say that negative comments regarding borrowing ideas from Raku are not helpful because they are not technical arguments.
Nor, in fact, are they social arguments unless you can explain why Perl borrowing from Python (core OO), C, sed, awk, and many other languages is OK while borrowing from Raku is not.
You wrote:

If you want this to be successful (and I want to see it successful myself), it needs to tend towards Perl5. This is just what the last 20 years has shown us. Otherwise, you're just risking the reimplementation (or vulnerable to the accusation) of Perl 6/Raku.

Raku has been the creation of a new language that attempted to fix all of Perl's problems at once while extending the language into heretofore unknown (to Perl) directions.
Corinna is:

a very limited attempt to fix one single area of Perl
almost at an RFC stage
largely implemented via Object::Pad
P5P discussions seem to imply that P5P is receptive to the idea.

Comparing Corinna to Raku is comparing a Toyota Corolla to an F-35 stealth fighter.
Update: Honestly, there's a hell of a lot more I'd steal from Raku if I could, but the languages have evolved in different directions and much of the brilliance in Raku simply can't be done in Perl.

TIme out, here. You wrote an aweful lot to counter and distract from my simple point; which I don't believe was missed. My point is simply this: if you are looking at concepts that are not famiar to journeymen Perl programmers (and indeed offer them as a natural progression), you will lose the people you need to make this successful. To do otherwise, and in particular, this case is to head in the direction of reimplementing Perl 6. Only this time you're going to reimplement it poorly. Is that negative? No, it's already bearing out. It's only "negative" if you don't like what I am stating.

There are two parts to this argument I haven't seen anyone else make yet, so here in the hope that this isn't at all a repeat.
Also, both of these points are made by reference to myself having actually written large amounts of real actual code using Object::Pad. [1].
Dynamic Method Generation
If twigil syntax exists, then methods that access slots can be dynamically added to classes by MOP access, by way of a :unbound method attribute. This tells the compiler not to resolve slot names at the time the method body is compiled:
  my $mref = method :unbound {
    $:aslot++;
  };

This "unbound method" is not yet useable, but can now be attached to a class by a MOP call, and only at that point we'll resolve the slot name in that class:
  $metaclass->add_slot( '$:aslot' );
  $metaclass->add_method( inc_slot => method :unbound { $:aslot++ } );

If instead, slot variables look identical to regular lexicals, then code of this form cannot be constructed. There would be no way to write the anonymous method {} reference in the first block of code above, without it failing to parse at compiletime because of an unrecognised variable name.
A mechanism does currently exist in Object::Pad to do this kind of thing, and it is Not Pretty:
  my $metaslot = $metaclass->add_slot( '$aslot' );
  $metaclass->add_method( inc_slot => sub {   # we can't use method
    my $self = shift;                         # because we're not method
    $metaslot->value($self)++;
  });

It turns what would be a simple efficient OP_SLOTPAD inside the method body into a closure capture of the $metaslot instance which invokes an lvalue accessor method on it at runtime, just to fetch the value of that slot. It works, but it's incredibly inefficient and removes most of the entire point of having these slot variables feel variable-like in the first place.
Surprising Lazy Initialization
One of the commonly-requested features from Moo(se?) users is "does it support lazy builders?". I have been hesitant to add these to Object::Pad itself for the reasons I explain below, but because people kept asking about it, I created a mechanism to allow 3rd-party attributes, and then created this:
https://metacpan.org/pod/Object::Pad::SlotAttr::LazyInit
This kind of thing is subtle to use in practice, because "slots look like lexicals". With Moo(se?), all instance data is accessed via accessor methods, and people are culturally used to the fact that methods can run code. They might print spurious warnings, or they might fail outright:
  use Moo;
  package OrangePeeler;

  has orange => ( is => 'lazy' );
  sub _build_orange {
    die "Not on a Tuesday, no" if (localtime)[6] == 2;
    warn "Maybe, maybe not" if rand > 0.5;
    return Orange->new;
  }

  sub peel {
    my $self = shift;

    # might die or warn but that's OK; we expect that
    my $orange = $self->orange;
    say "Peeling $orange...";
  }

Whereas, if all your slot variables look just like variables, then this might be considered surprising:
  use Object::Pad;
  class OrangePeeler;

  has $orange :LazyInit(_make_orange);
  method _make_orange {
    die "Not on a Tuesday, no" if (localtime)[6] == 2;
    warn "Maybe, maybe not" if rand > 0.5;
    return Orange->new;
  }

  method peel {
    # This variable interpolation itself might die or warn
    say "Peeling $orange...";
  }

By using a twigil and making slots "look different to variables", we can disarm this false feeling of safety, by reminding the programmer that these aren't just boring lexical variables, and that fun things may still happen:
  method peel {
    # This interpolation might die, but that's OK because it looks weird
    say "Peeling $:orange...";
  }

On Sat, Aug 14, 2021 at 1:45 PM Alexander Hartmaier <
@.***> wrote:

Do we want to support array and hash attributes (sorry, I hate the term
‚slot‘)?

In defense of the term "slot," it unambiguously means an instance variable
without implying anything about the implementation of the object.
This is a good thing. And is fully supported by method-style accessors
using current Perl syntax. (For a weak enough definition of "fully" that
denies that potential confusion between accessors and methods that do other
things might somehow be a problem.)

Some views, questions and suggestions from a "Normal Perl User".
"Java-Style"
Why exactly is this "Java-Style" not possible, as mentioned by OP?
It seems to me that it would be a good way to go, just from a user-perspective.
class Point {
    has ($.x, $.y) :param;

    method move ($x, $y) {
        $self->x = $x;
        $self->y = $y;
    }
}

Is it because it is not technically feasible to distinguish internal access from setter/getter method? But how is this solved in Java, since they can do it?
Can't Perl figure this out behind the curtain?

if :writer is set, $self->x works just fine
if :writer is not set, can't Perl distinguish somehow that in case of $self, the slot/attribute $x is meant?
if :writer is set, and I want to access the variable directly... I can't... is this important?

Arrow Dollar
Could $self->$x work? I have not seen it in this thread.
class Point {
    has ($.x, $.y) :param;

    method move ($x, $y) {
        $self->$x = $x;
        $self->$y = $y;
    }
}

My guess is, this is conflicting with some Perl-Golf, but I'm not sure.
I would find it quite intuitive, it reads as "the variable from me", instead of "the function from me".
Twigils
It seems to me, that twigils are a whole conception, where there are a lot of different characters with different meanings. So as an e.g. Raku-User there is a general concept to learn, which you can then use in different circumstances, by also choosing different special characters. Its' probably not good design to take just one single character from this concept to just build one Corinna-specific feature?
Also that :!attr as a twigil suggestion... the ! just "screams" to strong imho.
Dot Dot
I'm sad, that .. is already taken in Perl, because it would be UNIX-style for "up":
my $x = 12;
{
my $x = 'hello world';
say "inner x = $x";
say "outer x = $..x";

}
Well... ok, maybe I'm not sad. Not that beautiful as I imagined :-)

"Java-Style"
Why exactly is this "Java-Style" not possible, as mentioned by OP?
It seems to me that it would be a good way to go, just from a user-perspective.
class Point {
    has ($x, $y) :param;

    method move ($x, $y) {
        $self->x = $x;
        $self->y = $y;
    }
}

Is it because it is not technically feasible to distinguish internal access from setter/getter method? But how is this solved in Java, since they can do it?
Can't Perl figure this out behind the curtain?
* if `:writer` is set, `$self->x` works just fine

* if `:writer` is _not_ set, can't Perl distinguish somehow that in case of `$self`, the slot/attribute `$x` is meant?

* if `:writer` is set, and I want to access the variable directly... I can't... is this important?

Java method calls require parenthesis. This makes them distinct syntactically.
In perl this would mean overloading existing syntax with a lot of magic based on context, and would prevent many things that should work. Methods generates with :reader or :writer are not special. They are just shortcuts so you don't have to write the methods yourself. If a x method exists, how do you access the $x variable? How would you write a reader method manually if calling the method and accessing the variable use the exact same syntax?

Arrow Dollar
Could $self->$x work? I have not seen it in this thread.
class Point {
    has ($x, $y) :param;

    method move ($x, $y) {
        $self->$x = $x;
        $self->$y = $y;
    }
}

My guess is, this is conflicting with some Perl-Golf, but I'm not sure.
I would find it quite intuitive, it reads as "the variable from me", instead of "the function from me".

This is existing syntax for a method call. It will call the method name stored in the variable $x. It can't be overloaded without breaking existing syntax. And it would also require a lot of magic that would be confusing to document.

this would mean overloading existing syntax with a lot of magic based on context

hmmm... where have I seen this "context dependant magic" before..? it sounds so familiar, if not to say intimate :heart_eyes:

@leonerd

this kind of thing is subtle to use in practice, because "slots look like lexicals". With Moo(se?), all instance data is accessed via accessor methods, and people are culturally used to the fact that methods can run code. They might print spurious warnings, or they might fail outright:

I don't find this argument too compelling. There are already several mechanism supported by perl allowing one to run custom code when assigning to some variable (tie), or invoking simple operators like addition, stringification, etc. (overload). And well, everything using magic hocks.

I wasn't sure at first if non-scalar attributes were allowed by this RFC ... apparently they are, but what if they weren't: Could the whole twigil discussion be sidestepped by giving attributes their very own sigil instead?
Probably has a whole lot of different drawbacks but I think I haven't seen this option being discussed so far?
Please note that that wouldn't necessarily be my favorite, though: based on Ovids comment above, and the variants he describes, I'd prefer the twigil variant as the most readable (to me) one of them.
Though in the end I'll happily take whatever is chosen since it will be a huge step forward for Perl, anyway, and scratch my biggest itch (besides an "optional chaining" operator - like ?. in JavaScript - perhaps...).

Closing this ticket. We won't do this for v1, but perhaps it will be revisited later.

authors: Grinnz Ovid TBSliver aaronpriven abraxxa borisdaeppen davidnicol djerius duncand garu haarg heikojansen leonerd nrdvana oodler577 salva skirmess talexb tom-binary vrurg xenu yiyian-Lee

repo: Ovid/Cor


text:
Methods defined by "htmlClassUtilities" cannot be used in custom elements

Methods defined by "htmlClassUtilities" cannot be used in custom elements，but it is otherwise possible
replication code, based on the next .js project
// File path /pages/demo.tsx
import styles from '../styles/Index.module.css';
import dynamic from 'next/dynamic';

export default function IndexPage() {
  const DeepChat = dynamic(() => import('deep-chat-react').then((mod) => mod.DeepChat), {
    ssr: false,
  });

  return (

      <DeepChat
        introMessage={{html: '
<button class="custom-button">deep-chat</button>
<custom-element/>'}}
        htmlClassUtilities={{
          ['custom-button']: {
            events: {
              click: () => console.log('negative response'),
            }
          }
        }}
        request={{url: '/api/custom/chat-stream'}}
        stream={true}
      />

  );
}

custom elements
// File path /public/custom-element.js
class CustomElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({ mode: 'open' });
    const div = document.createElement('div');
    div.innerHTML = 'Hello, World!
<button class="custom-button">button</button>';
    shadow.appendChild(div);
  }
}

customElements.define('custom-element', CustomElement);

These two files are copied to the "nextjs" project, which can be reproduced by accessing the "http://localhost:3000/demo" after starting the project.
Sorry, the type of a property can only be a string.
Can I use an event proxy to make the child elements within the custom element trigger the events defined in the "htmlClassUtilities" through the bubble mechanism, and even then it is cumbersome to pass parameters out of the custom element.
If a custom element doesn't support function-type arguments like a react component, or implements "$emit" api for vue, communication with external components will always be an issue.
We're going to have to use window to communicate with custom components.
Hope you have a better suggestion.

Hi @buzhou9. Elements inside Custom Elements are not reachable by the getElementsByClassName method as they are not in the same DOM as Deep Chat, hence it cannot apply the htmlClassUtilities events/styling.
Nevertheless, you can use an event emitter workaround. First, apply an event to the custom element by adding a class to it.
<DeepChat
  introMessage={{
    html: '<custom-element class="custom-container"/>',
  }}
  htmlClassUtilities={{
    ['custom-container']: {
      events: {
        'custom-event': (event) => console.log(event),
      },
    },
  }}
  request={{url: '/api/custom/chat-stream'}}
/>

Then, inside your custom-element, add a dispatchEvent to the required button event:
class CustomElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({mode: 'open'});
    const customButton = document.createElement('button');
    customButton.innerText = 'button';
    customButton.onclick = () => {
      this.dispatchEvent(new CustomEvent('custom-event'));
    };
    shadow.appendChild(customButton);
  }
}

customElements.define('custom-element', CustomElement);

Your custom event will now communicate with Deep Chat via the custom-event type.
Currently, the TypeScript type can only handle event names in the GlobalEventHandlersEventMap object so it will give you an error, however this solution will work.
I will update the type in the next Deep Chat release.
Let me know if you have any further questions.
Thanks!

Hi @buzhou9. Elements inside Custom Elements are not reachable by the getElementsByClassName method as they are not in the same DOM as Deep Chat, hence it cannot apply the htmlClassUtilities events/styling.
Nevertheless, you can use an event emitter workaround. First, apply an event to the custom element by adding a class to it.
<DeepChat
  introMessage={{
    html: '<custom-element class="custom-container"/>',
  }}
  htmlClassUtilities={{
    ['custom-container']: {
      events: {
        'custom-event': (event) => console.log(event),
      },
    },
  }}
  request={{url: '/api/custom/chat-stream'}}
/>

Then, inside your custom-element, add a dispatchEvent to the required button event:
class CustomElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({mode: 'open'});
    const customButton = document.createElement('button');
    customButton.innerText = 'button';
    customButton.onclick = () => {
      this.dispatchEvent(new CustomEvent('custom-event'));
    };
    shadow.appendChild(customButton);
  }
}

customElements.define('custom-element', CustomElement);

Your custom event will now communicate with Deep Chat via the custom-event type.
Currently, the TypeScript type can only handle event names in the GlobalEventHandlersEventMap object so it will give you an error, however this solution will work. I will update the type in the next Deep Chat release.
Let me know if you have any further questions.
Thanks!

Hi @buzhou9. Elements inside Custom Elements are not reachable by the getElementsByClassName method as they are not in the same DOM as Deep Chat, hence it cannot apply the htmlClassUtilities events/styling.
Nevertheless, you can use an event emitter workaround. First, apply an event to the custom element by adding a class to it.
<DeepChat
  introMessage={{
    html: '<custom-element class="custom-container"/>',
  }}
  htmlClassUtilities={{
    ['custom-container']: {
      events: {
        'custom-event': (event) => console.log(event),
      },
    },
  }}
  request={{url: '/api/custom/chat-stream'}}
/>

Then, inside your custom-element, add a dispatchEvent to the required button event:
class CustomElement extends HTMLElement {
  constructor() {
    super();
    const shadow = this.attachShadow({mode: 'open'});
    const customButton = document.createElement('button');
    customButton.innerText = 'button';
    customButton.onclick = () => {
      this.dispatchEvent(new CustomEvent('custom-event'));
    };
    shadow.appendChild(customButton);
  }
}

customElements.define('custom-element', CustomElement);

Your custom event will now communicate with Deep Chat via the custom-event type.
Currently, the TypeScript type can only handle event names in the GlobalEventHandlersEventMap object so it will give you an error, however this solution will work. I will update the type in the next Deep Chat release.
Let me know if you have any further questions.
Thanks!

Thanks, great idea！

The TypeScript types have now been updated to support custom events in Deep Chat version 1.4.11.
See the htmlClassUtilities docs for more.

repo: OvidijusParsiunas/deep-chat


text:
replying in comments sometimes adds the reply at the top of the comment thread

but sometimes if you refresh the page it fixes itself, so might just be a transient front-end thing

This seems to be mostly resolved and was never reproducibly reliably anyway so I am closing for now.

authors: alasdairwilson martinjrobins

repo: OxfordRSE/gutenberg


text:
Using reflection to use reflection to get type

---
Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/11908397-using-reflection-to-use-reflection-to-get-type?utm_campaign=plugin&utm_content=tracker%2F6855523&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F6855523&utm_medium=issues&utm_source=github).

Should be fixed now.

repo: OxideMod/Oxide


text:
Default namespaces

Would it make sense to prefix the default namespaces that are published in the vendor config with App\? So something like this:
	'namespaces' => [
	    'contracts' => 'App\Repositories\Contracts',
	    'repositories' => 'App\Repositories\Eloquent',
	],

Happy to submit a PR if that makes sense :+1:

You know Laravel has a command called php artisan app:name to set a requested base namespace for your application. The package is already using it.
You can have a look at the command MakeRepositoryCommand, at line 154:
$this->laravel->getNamespace()

is being used to get that.
Please let me know about your thoughts.

https://github.com/OzanKurt/Repoist/pull/21

I can confirm this is now fixed, thank you! 👍

authors: OzanKurt mattsims

repo: OzanKurt/Repoist


text:
Add BytesStatistics information to table for BYTES features.

As requested, add num unique and average length fields from BytesStatistics to the categorical table for features of type BYTES.

This fixes #2

repo: PAIR-code/facets


text:
🛑 PATH08's Site is down

In 05a8b3e, PATH08's Site (https://www.path08.gq) was down:

HTTP code: 0
Response time: 0 ms

Resolved: PATH08's Site is back up in 8a7e7d9.


text:
Bug fix in CMEC driver climatologies

This fixes a typo in the CMEC driver automatic climatologies function. This also replaces "Float32" with "float32" as a type in the pcmdi_compute_climatologies script, as "Float32" was not being recognized as a type in Python 3.7.

@gleckler1 I found a typo and a type issue last Friday that I didn't squeeze into the CMEC driver PR in time.


text:
ViewFormsDashboardUseCase implemented

ViewFormsDashboard Use Case
Motivation and Context
Creates one of the use cases in our user journey. This brings forth a list of forms belonging to a specific Claim and uses both the {claimId} and {clientId} to confirm this. This will be the core functionality required for the Forms Dashboard page that each Claim has. Returns an empty list if client does not contain the specified claimId or if claimId does not exist. Since the page should only be accessed after a client and claim exists, the empty list will serve as indicates something has gone wrong.
Your Changes
Implemented all classes and methods as required by CA for the ViewFormsDashboard Use Case. Namely have added to the interface_adaptors and use_case packages. Additionally, have added a couple of methods into the DAO to provide functionality necessary for the use case. See changes in code.
Type of change (select all that apply):
[x] New feature (non-breaking change which adds functionality)
Notes for Reviewer
To test, run FlexApplication > go to http://localhost:8080/1234/1010/forms or http://localhost:8080/5678/1002/forms.
The format of the URL is localhost:8080/{clientId}/{claimId}/forms
This should return the forms involved in claim #1010 (formId should be 12) and #1002 (formId should be 2) respectively. Also, clientIds that do not exist or claimIds that do not belong to the Client specified by clientId should return an empty list of forms. You can try this by entering a random clientID for claim 1010 or a random claimID for client 1234 and observe the response.
Checklist

[x] I have performed a self-review of my own code.

Code Review
✅ Coding style
✅ Correctness (code runs)
✅ Adherence to Clean Architecture + SOLID
✅ Javadoc (Requires proper Javadocs)
✅ Clear pull request information
Comments:

JavaDoc Comments are very detailed on for MongoDAO, which does bulk of tasks. Not a lot of Javadoc in the use case files, but since adherence to CA, these are not necessary.
Runs exactly as described when run locally.
Next Steps: Testing with front-end implementation.

Update: End-to-End testing completed and fully functional for use case!

authors: lana-w vithushon

repo: PDFlex/pdflex-backend


text:
404 no Gh-Pages

Github pages reporta o erro: "Your site is having problems building: Validation failed: User must be a human, not an Organization"

Resolvida em 52c2fed

repo: PETComputacaoUFPR/pet-css