defmodule Foo do
defmacro __using__(_) do
Module.register_attribute(__CALLER__.module, :foo, persist: true)
Module.put_attribute(__CALLER__.module, :foo, :bar)
The reason why I don't want to stash the ast from the parent module and inject that quoted form into the child is because of private functions
If a function definition requires calling a private function, I could override Kernel.defp and stash/inject into the inheriting module but if any of the parents in the inheritance chain implement a similarly named private function they would confilct. Private functions aren't intended to be implemented, just the public ones.
If I was really ambitious I could do a static analysis of the quoted form to determine if any function calls are made to fucntions that are not availble in the stashed local scope. If it cannot find then it will write a function delegate to the parent module's public definition. This would mean that any functions that fall under this situation cannot call a private function of they would cause a compiler error.
I want you to implement all of the missing Event classes drived from the "Interfaces based on Event" list in the Event MDN page: https://developer.mozilla.org/en-US/docs/Web/API/Event#interfaces_based_on_event
First start by analyzing GenDOM.Event in lib/gen_dom/event.ex, GenDOM.UIEvent in lib/gen_dom/ui_event.ex, GenDOM.MouseEvent in lib/gen_dom/mouse_event.ex and GenDOM.PointerEvent in lib/gen_dom/pointer_event.ex see how they inherit from one another using GenObject who's docs are at: https://hexdocs.pm/gen_object/index.html
when converting from the spec to Elixir you convert camelcased named like fooBar
into snakecase like foo_bar
.
any unused variables in a function from the function defintion should have a leading underscore to prevent warnings
use the list from the Interfaces based on Event list and find all of the unimplemented classes. Then create elixir files for each in lib/gen_dom corresponding to the name'd class and create modules in each file nested under GenDOM.
I want you to visit the M
defmodule LivingThing do | |
use GenObject, [ | |
..living traits... | |
] | |
...living functions... | |
end | |
defmodule Mammal do | |
use LivingThing, [ | |
... |
Build the Wasm bundle with:
mix bundle_phoenix_live_view --phoenix v1.8.0-rc.3 --phoenix-live-view v1.1.0-rc.1
There is a Rust plugin that handles interfacing between JS and Elixir at priv/browser_plugin/src/lib.rs
.
To define a function in Elixir that Wasm can call, use the defimport
macro:
# Racing.org Platform - High-Level Requirements | |
## Project Objective | |
Build Racing.org as a free, comprehensive regatta management platform that introduces and promotes the OpenVPP rating system while providing modern, mobile-first regatta management tools that surpass existing commercial platforms in user experience and functionality. | |
--- | |
## Core Business Requirements |
Primary Objective: Serve as the central hub for sailing that connects boat owners, race organizers, and crew while promoting fair racing through OpenVPP and free platform access.
Core User Personas:
View Markup Language (VML) is a markup language derived from SGML, designed to represent a XAML-based UI for unidirectional, server-driven rendering on the WinUI 3 platform. It is designed to be a subset of XAML concepts, making it highly idiomatic for Windows developers.
Specification Note 1.1: Scope The VML specification is concerned exclusively with the structure and rendering of UI elements. It is a unidirectional standard (server-to-client). Mechanisms for handling user interactions, events, and data binding (
{Binding}
,{x:Bind}
) are explicitly outside the scope of this document.
View Markup Language (VML) is a markup language derived from SGML, designed to represent composable UI frameworks for unidirectional, server-driven rendering. This specification defines the conversion from a server-side view model to VML for use with Jetpack Compose.
Specification Note 1.1: Scope The VML specification is concerned exclusively with the structure and rendering of composables. It is a unidirectional standard (server-to-client). Mechanisms for handling user interactions, actions, and client-to-server state changes are explicitly outside the scope of this document.