From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on starla X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 Received: from nue.mailmanlists.eu (nue.mailmanlists.eu [94.130.110.93]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id E56C61F4CC for ; Tue, 17 Dec 2024 23:51:29 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=ml.ruby-lang.org header.i=@ml.ruby-lang.org header.a=rsa-sha256 header.s=mail header.b=ct3r+qL2; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=AioWpnGs; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ml.ruby-lang.org; s=mail; t=1734479486; bh=Sb+cR0xKjiJe4eRcBO5/77/RDqbfyfgs83whPOMD1A8=; h=Date:References:To:Reply-To:Subject:List-Id:List-Archive: List-Help:List-Owner:List-Post:List-Subscribe:List-Unsubscribe: From:Cc:From; b=ct3r+qL250s1evRTLYQsJv4eoABeSMOWZbPhZdMN1YDtKImI2IImHhm/ZxFsKg2vh 2nlroQCLT7tNfaLDeZ7UG6ZvLbnnaueAN4v+OokfQF/nTiOkZg6LxmY60FNvfLnMsN Urxceykpvutw/30OJQ8BQ7JzjYLWEeK9vV1g50+I= Received: from nue.mailmanlists.eu (localhost [IPv6:::1]) by nue.mailmanlists.eu (Postfix) with ESMTP id D8F1944EB1 for ; Tue, 17 Dec 2024 23:51:26 +0000 (UTC) Authentication-Results: nue.mailmanlists.eu; dkim=pass (2048-bit key; unprotected) header.d=ruby-lang.org header.i=@ruby-lang.org header.a=rsa-sha256 header.s=s1 header.b=AioWpnGs; dkim-atps=neutral Received: from s.wfbtzhsw.outbound-mail.sendgrid.net (s.wfbtzhsw.outbound-mail.sendgrid.net [159.183.224.105]) by nue.mailmanlists.eu (Postfix) with ESMTPS id 4821E44E6D for ; Tue, 17 Dec 2024 23:51:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ruby-lang.org; h=from:references:subject:mime-version:content-type: content-transfer-encoding:list-id:to:cc:content-type:from:subject:to; s=s1; bh=2euoKqaAiHgSRpWC6SH2pWbO20EFMfKIi8EkvrkL3to=; b=AioWpnGs7bFyJ7M031vYhDxE8tWzWf6MyvPapKQmDo1qqKejtjd+7SOe6oNFEw9ERKaF fZV76GqYd0qhLMwRaPWS42pjtNakTWiaCmaxIWrjQ8diW54NOdH6fjpfVpoxenLVJhvngG ktI80pHF0UtX5EfMGYQdokcnOfDGUtTbUcE6aqFLJK6YciAyAvWPOyaWNrkMf4II0kdFem QdxngabQsOyPD3LM2eYHAn8AgCKwqM/ZRNetL2IEx9WUkj1/60vovUWLcuWzMIDY2A23Ab tX33/Y3GNYvH1psI4U9t1DSSY0HKsGMOXYDoF5wZMKX4+xlQbcWHHZcet07J5Z3Q== Received: by recvd-5f54b5d587-dffwj with SMTP id recvd-5f54b5d587-dffwj-1-67620E79-19 2024-12-17 23:51:21.699335629 +0000 UTC m=+2860121.056442954 Received: from herokuapp.com (unknown) by geopod-ismtpd-11 (SG) with ESMTP id -VSjRVQiTWmxpYyDAH4FNg for ; Tue, 17 Dec 2024 23:51:21.646 +0000 (UTC) Date: Tue, 17 Dec 2024 23:51:21 +0000 (UTC) Message-ID: References: Mime-Version: 1.0 X-Redmine-Project: ruby-master X-Redmine-Issue-Tracker: Bug X-Redmine-Issue-Id: 20943 X-Redmine-Issue-Author: nobu X-Redmine-Issue-Priority: Normal X-Redmine-Sender: shan X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-Redmine-MailingListIntegration-Message-Ids: 96961 X-SG-EID: =?us-ascii?Q?u001=2E9fGRHcaur0AuvitC=2F1zdJ7W0yF4MIWkxScnW56JP3D1Ru6E8cp4fwU50h?= =?us-ascii?Q?hG=2FIY2Xn1m8ku39wNL1Ycq7qVKPg2at8MlH86pC?= =?us-ascii?Q?QD+axk8pzTXTxbw3OiweGjIbVPe6kzv+R+ZZIw=2F?= =?us-ascii?Q?2msyhLnssYCBw5j9infZLkIceOpbvb3xs2j0qfu?= =?us-ascii?Q?MOzehy9DQmO0RbUzmkm1gfWN7DiPxkCxNKvxNA2?= =?us-ascii?Q?4nJL3mPhyeCe+Cmw2JUwHxliiD3qZla0jTxh49s?= =?us-ascii?Q?YzHstyEyyXwASqaBhMsx+hN6SA=3D=3D?= To: ruby-core@ml.ruby-lang.org X-Entity-ID: u001.I8uzylDtAfgbeCOeLBYDww== Message-ID-Hash: KBNFFFGLW22YFHPMT6B7A6IHNGRH2RMC X-Message-ID-Hash: KBNFFFGLW22YFHPMT6B7A6IHNGRH2RMC X-MailFrom: bounces+313651-b711-ruby-core=ml.ruby-lang.org@em5188.ruby-lang.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9 Precedence: list Reply-To: Ruby developers Subject: [ruby-core:120284] [Ruby master Bug#20943] Constant defined in `Data.define` block List-Id: Ruby developers Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: "shan (Shannon Skipper) via ruby-core" Cc: "shan (Shannon Skipper)" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Issue #20943 has been updated by shan (Shannon Skipper). byroot (Jean Boussier) wrote in #note-2: > Which is a bit wasteful as you define two classes instead of one, but not a big deal. I agree the extra class being created is minor, but I'm slightly more bothered by the anonymous class in the ancestry. ```ruby [Something, #, Struct, ... ] ``` > I kinda wish this would be valid syntax: > > ```ruby > class Something = Struct.new(:a, :b) > ... > end > ``` I'd like that too. That same pattern would be great for both `Struct` and `Data` from my vantage. Or if both could keep constants in scope within `do` blocks, but would that be consider breaking? Too late for Data? I'd like it. It seems like options include: 1. Change `Data.define do` block scope for constants 2. Add a new `Something = Data.define` or similar syntax 3. Recommend reopening classes in docs 4. Recommend inheritance in docs 5. Keep the status quo of defining a constant outside the scope in docs That ^ list happens to be roughly in my personal order of preference from top to bottom. :) Having both 1 and 2 would also be an option. I wonder if changing documentation to something that keeps `NONE` inside the module is worth doing in the short term? If syntax adjustments are decided against, I'd rather just recommend reopening `Data` and `Struct` classes rather than the slight back bending with existing solutions like `self::` prefix or `< Data.define`. On the other hand, I'd love to see a syntax adjustment to make it easier to define a constant within a `Data` without reopening the class. ---------------------------------------- Bug #20943: Constant defined in `Data.define` block https://bugs.ruby-lang.org/issues/20943#change-111049 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- >>From https://github.com/ruby/ruby/pull/12274: > A couple times in code review I've seen constants inadvertently leak to top level from within a `Struct` or `Data` do block. I think it would be nice to show reopening the `Data` class when a constant is defined, so the constant is defined within the namespace. In this case, `Measure::NONE` instead of top level `Object::NONE`. It would also show readers that it's okay to reopen a `Data` class, which seems nice since some folk might not realize. Thanks for considering! However, I think that `NONE` probably might be intended to be defined under `Measure`. Current: ```ruby Measure = Data.define(:amount, :unit) do NONE = Data.define end p NONE #=> NONE ``` Another: ```ruby Measure = Data.define(:amount, :unit) do NONE = Data.define p NONE #=> Measure::NONE end p NONE # uninitialized constant NONE (NameError) ``` @zverok How do think? -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/