mortymer 0.0.9 → 0.0.11

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 6e65cf959fadc75136e6438cb640a19a62315987b7825659d24977ca23df81f1
-  data.tar.gz: '069dac56627ea192bb9f331f4e876f78d0a3a7a2699b4dee484ab591183cb2ce'
+  metadata.gz: 1aaae1b0260575ca60caeb8b676577f39766162d8127a6266e1c49e168e11265
+  data.tar.gz: 0f92cfaa12e157dcb4954259dd284b7b46f7305dd912d84a55fef597107997f7
 SHA512:
-  metadata.gz: 80c1c763739396b3f8bfbe5c2da14ab17f25536ebdfbfc39af256ecb51a706b3fc2994204d992faa4e7fb5a912c32252b86687f4f2fbe115ba9bdf1bafb3ebee
-  data.tar.gz: 7e67f9ba29deead0905eaf598523aa93566a482925c94b2d635d584415d06e7184f064524ca9edf713002f5cb0cab10a2e25c781dc762ffa9eb51be48589a9b6
+  metadata.gz: c5c3932bfb5b0daf315af6f8f4a1ef36b0a448229fd15b9c71f7c8699d8f41fcfeb8a5858686b55d6c7905628936908512e97537b6a5ec0024061f6b3f4bcd60
+  data.tar.gz: df393725ff3c29b36ede225c046f8f27cbfea156f09917cd1976b8c3188f9dafa5e57e0aa0876a378f7afda62ab0ea06b17f500d0f46f6d8caae18c249c13acf

data/docs/.vitepress/config.mts

@@ -7,7 +7,10 @@ export default defineConfig({
   description:
     "Standalone API definition for ruby frameworks based on dry.rb. Rails compatible from day 0 with a full Ruby flavored dependency injection engine.",
   markdown: {
-    theme: "catppuccin-mocha",
+    theme: {
+      light: "catppuccin-latte",
+      dark: "catppuccin-mocha",
+    },
   },
   themeConfig: {
     nav: [
@@ -36,7 +39,17 @@ export default defineConfig({
             { text: "Type System", link: "/guide/type-system" },
             {
               text: "Dependency Injection",
-              link: "/guide/dependency-injection",
+              items: [
+                {
+                  text: "Introduction to DI in Ruby",
+                  link: "/guide/dependency-injection",
+                },
+
+                {
+                  text: "DI in Mortymer",
+                  link: "/guide/mortymer-dependency-injection",
+                },
+              ],
             },
             { text: "Error Handling", link: "/guide/error-handling" },
           ],
@@ -63,12 +76,12 @@ export default defineConfig({
     },
 
     socialLinks: [
-      { icon: "github", link: "https://github.com/yourusername/morty" },
+      { icon: "github", link: "https://github.com/adriangs1996/morty" },
     ],
 
     footer: {
       message: "Released under the MIT License.",
-      copyright: "Copyright © 2024-present",
+      copyright: "Copyright © 2025-present",
     },
   },
 });

data/docs/.vitepress/theme/style.css

@@ -1,5 +1,3 @@
-
 html {
   font-family: Arial, Helvetica;
 }
-

data/docs/guide/dependency-injection.md

@@ -0,0 +1,205 @@
+# Dependency Injection
+
+## What is Dependency Injection?
+
+Dependency Injection (DI) is a design pattern that implements Inversion of Control (IoC) for managing dependencies between components.
+Instead of having your components create or find their dependencies, these dependencies are "injected" into the component from the outside.
+
+Consider this example without dependency injection:
+
+```ruby
+class UserService
+  def initialize
+    @repository = UserRepository.new
+    @mailer = UserMailer.new
+  end
+
+  def create_user(params)
+    user = @repository.create(params)
+    @mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+In the above code, UserService explicitly creates instances of UserRepository and UserMailer,
+making it tightly coupled to these dependencies. When arguing why DI is usefull, commonly
+the following arguments arise:
+
+- <b>Harder to Test</b>: We cannot easily substitute UserRepository or UserMailer with mocks or stubs during testing.
+  This is not entirely true, as in Ruby you can mock pretty much everything, so this does not make a really good
+  argument, although mocking becomes easier when using DI.
+
+- <b>Less Flexible</b>: If we later decide to use a different repository or mailer, we must modify UserService directly.
+  Think if we have two implementations of UserMailer, for some reason you want to send emails using SendGrid, but other times
+  you want to send emails using your cloud provider solution, or your custom server. UserService really does not cares
+  about how this is implemented or where the emails goes, it just need to send an email for whatever channel we choose.
+
+- <b>Tightly Coupled</b>: UserService is responsible for constructing its dependencies, making it harder to manage and extend.
+
+A DI-based approach improves flexibility and testability:
+
+```ruby
+class UserService
+  def initialize(repository:, mailer:)
+    @repository = repository
+    @mailer = mailer
+  end
+
+  def create_user(params)
+    user = @repository.create(params)
+    @mailer.send_welcome_email(user)
+    user
+  end
+end
+
+# Inject dependencies
+repository = UserRepository.new
+mailer = UserMailer.new
+service = UserService.new(repository, mailer)
+```
+
+Now, UserService does not need to know how to instantiate its dependencies. Instead, they are provided externally.
+
+## The Ruby Community’s Perspective on Dependency Injection
+
+Rubyists often prefer simplicity and flexibility, so DI is not as commonly enforced as in other static-typed languages like Java or C#. This is a topic that spans very different point of views. Just to give an example, read the following Reddit thread
+<https://www.reddit.com/r/ruby/comments/10x6w8q/dependency_injection/>
+
+It discusses the use of Dependency Injection (DI) in Ruby, particularly within the context of Ruby on Rails (RoR). Several key points emerge from the conversation:
+
+- <b>Testing and Metaprogramming</b>: One user notes that in languages like Java and PHP, DI is often employed to facilitate testing by allowing the injection of mock dependencies. However, in Ruby, the language's metaprogramming capabilities enable developers to mock dependencies directly without the need for DI containers, potentially simplifying the codebase.
+
+- <b>Code Organization and Dependency Tracking</b>: Another perspective suggests that DI serves as a method to organize code systematically and maintain an efficient track of dependencies. Improved testability is viewed as a beneficial byproduct of this organization.
+
+- <b>Coupling and Code Simplicity</b>: It's acknowledged that while avoiding DI can lead to simpler code, it may also result in tighter coupling between components. This necessitates a careful balance to ensure that the code remains maintainable without becoming overly complex.
+
+In summary, the thread reflects a nuanced view within the Ruby community regarding DI. Some developers prefer to leverage Ruby's dynamic features and metaprogramming to manage dependencies, while others advocate for DI as a means to achieve cleaner code organization and dependency management. The choice often depends on the specific requirements and context of the project.
+
+## The way of Mortymer
+
+I think that DI is necessary, no matter how you decide to handle it. To be aware of
+what your functionality depends on is crucial when evaluating the impact of changes. While
+testability benefits exist in Ruby through its powerful metaprogramming capabilities, the main
+advantage of DI is the explicitness about what your code does and what it depends on. This
+transparency makes the code more maintainable and easier to understand.
+
+Additionally, DI naturally supports the Open-Closed Principle (the 'O' in SOLID): when
+dependencies are injected rather than hardcoded, new functionality can be added by creating
+new implementations of interfaces rather than modifying existing code. While it's technically
+possible to extend functionality without DI in Ruby, doing so often requires more complex
+metaprogramming or direct code modifications, making the system harder to maintain and understand
+over time.
+
+With this in mind, we can explore different approaches to do Dependency Injection in Ruby.
+
+### Constructor Injection
+
+This is by far the most common implementation of DI. This includes initialization of objects
+and dependencies are passed as parameters. In ruby, we would do it like:
+
+```ruby
+class UserService
+  def initialize(repository: UserRepository.new, mailer: UserMailer.new)
+    @repository = repository
+    @mailer = mailer
+  end
+
+  def find_user(user_id)
+    # Use @repository and @mailer
+  end
+end
+```
+
+Note how we added a default value to the repository and mailer dependency. This is a convenience
+that will let programmers to initialize easily an `UserService` using just the `#new` method
+and make it clearer which interface ( any repository we use here must conform to the same interface
+as `UserRepository` and the same goes to `UserMailer`)
+
+### Method injection
+
+Passing dependencies directly to a method when needed:
+
+```ruby
+class UserService
+  def create_user(params, repository: UserRepository.new, mailer: UserMailer.new)
+    user = repository.create(params)
+    mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+This approach is less common, but is really useful when you have some classes with different
+dependencies for different methods. This is generally easy to avoid tough, by using the Command Pattern
+or Service Objects with constructor Injection.
+
+### Global Injection
+
+Global Injection is often used in frameworks like Ruby on Rails,
+where dependencies can be globally configured and injected throughout the application.
+
+```ruby
+# config/initializers/dependencies.rb
+MyAppDependencies = {
+  user_repository: UserRepository.new,
+  mailer: UserMailer.new
+}
+
+# In the service
+class UserService
+  def initialize(repository: MyAppDependencies[:user_repository], mailer: MyAppDependencies[:mailer])
+    @repository = repository
+    @mailer = mailer
+  end
+
+  def create_user(params)
+    user = @repository.create(params)
+    @mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+### Dependency Injection Containers
+
+Gems like dry-container and dry-auto_inject help manage dependencies in larger applications:
+
+```ruby
+class UserService
+  include Import["repositories.user_repository", "mailers.user_mailer"]
+
+  def create_user(params)
+    user = user_repository.create(params)
+    user_mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+This category is where Mortymer fit in. Actually, DI Containers all essentially do the same: to make developer
+life easier when declaring and handling this dependencies. For example, the first approach we discuss, **Constructor Injection**,
+becomes really tedious to use, there is a lot of boilerplate code to write. Imaging all the time writing the same
+initialize function receiving your dependencies and setting the instance variables. Well, gems do exactly that, remove
+the boilerplate for you. The main difference is in how they do it and what you get in return. Gems like dry-auto_inject
+, like shown above, focus on constants resolutions through strings, and dynamically created read methods for your dependencies.
+
+Mortymer does it in a very different way. We favor dependencies being referenced using constants, because that
+empowers code navigation and tools like LSP with go to definitions and such features. Also, referencing constants, allows
+us to use a similar API that is found on strongly-typed languages like Java. The other main difference is that Mortymer will
+not create methods on the fly for you, you will get instance variables. The same example using Mortymer looks like:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject Repositories::UserRepository
+  inject Mailers::UserMailer, as: :mailer
+
+  def create_user(params)
+    user = @user_repository.create(params)
+    @mailer.send_welcome_email(user)
+    user
+  end
+end
+```

data/docs/guide/mortymer-dependency-injection.md

@@ -0,0 +1,398 @@
+# Mortymer Dependency Injection Guide
+
+## Overview
+
+Mortymer provides a powerful yet simple dependency injection system that favors explicit constant references and instance variables over dynamic method creation. This guide will walk you through the various ways to use dependency injection with Mortymer.
+
+## Basic Usage
+
+### Simple Injection
+
+The most basic form of dependency injection in Mortymer uses the `inject` directive:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository
+
+  def find_user(id)
+    @user_repository.find(id)
+  end
+end
+```
+
+When you include `Mortymer::DependenciesDsl`, you get access to the `inject` directive. This will:
+
+1. Create an instance variable `@user_repository`
+2. Automatically initialize it with an instance of `UserRepository`
+
+### Custom Variable Names
+
+You can customize the instance variable name using the `as` option:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository, as: :users
+
+  def find_user(id)
+    @users.find(id)
+  end
+end
+```
+
+### Multiple Dependencies
+
+You can inject multiple dependencies in a single class:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository
+  inject UserMailer
+  inject Logger, as: :logger
+
+  def create_user(params)
+    @logger.info("Creating new user")
+    user = @user_repository.create(params)
+    @user_mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+## Advanced Usage
+
+### Dependency Scopes
+
+Mortymer supports different scopes for dependencies:
+
+#### Singleton Scope (Default)
+
+By default, dependencies are singleton-scoped, meaning the same instance is shared across the application:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository # Singleton by default
+end
+```
+
+#### Request Scope
+
+For dependencies that should be unique per request:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository, scope: :request
+end
+```
+
+#### Transient Scope
+
+For dependencies that should be newly instantiated every time:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository, scope: :transient
+end
+```
+
+### Factory Registration
+
+You can register custom factory methods for your dependencies:
+
+```ruby
+Mortymer.configure do |config|
+  config.register_factory(UserRepository) do
+    UserRepository.new(connection: DatabaseConnection.current)
+  end
+end
+```
+
+### Interface-Based Dependencies
+
+Mortymer supports interface-based dependency injection:
+
+```ruby
+module UserRepositoryInterface
+  def find(id)
+    raise NotImplementedError
+  end
+end
+
+class PostgresUserRepository
+  include UserRepositoryInterface
+  # implementation
+end
+
+class MongoUserRepository
+  include UserRepositoryInterface
+  # implementation
+end
+
+# Register implementation
+Mortymer.configure do |config|
+  config.register_implementation(UserRepositoryInterface, PostgresUserRepository)
+end
+
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserRepositoryInterface
+end
+```
+
+## Testing
+
+### Mocking Dependencies
+
+Mortymer makes it easy to mock dependencies in tests:
+
+```ruby
+RSpec.describe UserService do
+  let(:repository_mock) { instance_double(UserRepository) }
+  let(:mailer_mock) { instance_double(UserMailer) }
+
+  before do
+    Mortymer.stub_dependency(UserRepository, repository_mock)
+    Mortymer.stub_dependency(UserMailer, mailer_mock)
+  end
+
+  it "creates a user" do
+    service = UserService.new
+    expect(repository_mock).to receive(:create)
+    expect(mailer_mock).to receive(:send_welcome_email)
+
+    service.create_user(name: "John")
+  end
+end
+```
+
+### Test-Specific Implementations
+
+You can also register test-specific implementations:
+
+```ruby
+class TestUserRepository
+  include UserRepositoryInterface
+
+  def initialize
+    @users = {}
+  end
+
+  def find(id)
+    @users[id]
+  end
+end
+
+RSpec.describe UserService do
+  before do
+    Mortymer.register_implementation(UserRepositoryInterface, TestUserRepository)
+  end
+end
+```
+
+## Best Practices
+
+### 1. Keep Dependencies Explicit
+
+Always use explicit constant references rather than strings for dependencies:
+
+```ruby
+# Good
+inject UserRepository
+
+# Avoid
+inject "user_repository"
+```
+
+### 2. Use Meaningful Names
+
+Choose descriptive names for your dependencies:
+
+```ruby
+# Good
+inject UserRepository, as: :active_users_repository
+
+# Less Clear
+inject UserRepository, as: :repo
+```
+
+### 3. Group Related Dependencies
+
+Keep related dependencies together and organize them logically:
+
+```ruby
+class UserService
+  include Mortymer::DependenciesDsl
+
+  # Authentication dependencies
+  inject AuthenticationService
+  inject TokenGenerator
+
+  # User management dependencies
+  inject UserRepository
+  inject UserMailer
+
+  # Logging/Monitoring
+  inject Logger
+  inject MetricsCollector
+end
+```
+
+### 4. Interface Segregation
+
+Create focused interfaces for your dependencies:
+
+```ruby
+module UserReader
+  def find(id); end
+  def list; end
+end
+
+module UserWriter
+  def create(attributes); end
+  def update(id, attributes); end
+end
+
+class UserRepository
+  include UserReader
+  include UserWriter
+end
+
+class UserService
+  include Mortymer::DependenciesDsl
+
+  inject UserReader  # Only inject what you need
+end
+```
+
+## Common Patterns
+
+### Service Objects
+
+```ruby
+class CreateUser
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository
+  inject UserMailer
+  inject UserValidator
+
+  def call(params)
+    @user_validator.validate!(params)
+    user = @user_repository.create(params)
+    @user_mailer.send_welcome_email(user)
+    user
+  end
+end
+```
+
+### Decorators
+
+```ruby
+class LoggedUserRepository
+  include Mortymer::DependenciesDsl
+
+  inject UserRepository
+  inject Logger
+
+  def find(id)
+    @logger.info("Finding user: #{id}")
+    result = @user_repository.find(id)
+    @logger.info("Found user: #{result&.id}")
+    result
+  end
+end
+```
+
+## Configuration
+
+### Global Configuration
+
+```ruby
+Mortymer.configure do |config|
+  # Register default implementations
+  config.register_implementation(UserRepositoryInterface, PostgresUserRepository)
+
+  # Register factories
+  config.register_factory(Logger) do
+    Logger.new($stdout).tap do |logger|
+      logger.level = Rails.env.production? ? :info : :debug
+    end
+  end
+
+  # Configure scopes
+  config.set_scope(UserSession, :request)
+end
+```
+
+### Environment-Specific Configuration
+
+```ruby
+# config/initializers/mortymer.rb
+Mortymer.configure do |config|
+  if Rails.env.test?
+    config.register_implementation(UserRepositoryInterface, TestUserRepository)
+  elsif Rails.env.development?
+    config.register_implementation(UserRepositoryInterface, DevUserRepository)
+  else
+    config.register_implementation(UserRepositoryInterface, ProductionUserRepository)
+  end
+end
+```
+
+## Troubleshooting
+
+### Common Issues
+
+1. **Circular Dependencies**
+
+```ruby
+# This will raise a CircularDependencyError
+class UserService
+  include Mortymer::DependenciesDsl
+  inject AccountService
+end
+
+class AccountService
+  include Mortymer::DependenciesDsl
+  inject UserService  # Circular dependency!
+end
+```
+
+Solution: Refactor to remove the circular dependency or use method injection.
+
+2. **Missing Dependencies**
+
+```ruby
+# This will raise a DependencyNotFoundError
+class UserService
+  include Mortymer::DependenciesDsl
+  inject NonExistentService
+end
+```
+
+Solution: Ensure all dependencies are properly registered or the constants exist.
+
+3. **Scope Conflicts**
+
+```ruby
+# This might cause issues
+class UserService
+  include Mortymer::DependenciesDsl
+  inject SessionManager, scope: :request  # Request-scoped
+  inject UserRepository  # Singleton-scoped
+end
+```
+
+Solution: Be careful mixing different scopes and ensure it makes sense for your use case.

data/lib/mortymer/container.rb

@@ -108,9 +108,7 @@ module Mortymer
     def resolve_implementation(implementation, key, resolution_stack)
       case implementation
       when Proc
-        result = instance_exec(&implementation)
-        registry[key] = result
-        result
+        instance_exec(&implementation)
       when Class
         resolve_class(implementation, key, resolution_stack)
       else
@@ -119,14 +117,12 @@ module Mortymer
     end
 
     # Resolve a class implementation with its dependencies
-    def resolve_class(klass, key, resolution_stack)
-      instance = if klass.respond_to?(:dependencies)
-                   inject_dependencies(klass, resolution_stack)
-                 else
-                   klass.new
-                 end
-      registry[key] = instance
-      instance
+    def resolve_class(klass, _key, resolution_stack)
+      if klass.respond_to?(:dependencies)
+        inject_dependencies(klass, resolution_stack)
+      else
+        klass.new
+      end
     end
 
     # Inject dependencies into a new instance

data/lib/mortymer/contract.rb

@@ -4,11 +4,14 @@ require_relative "moldeable"
 require "dry/validation"
 require "dry/validation/contract"
 require_relative "generator"
+require_relative "types"
+require_relative "struct_compiler"
 
 module Mortymer
   # A base model for defining schemas
   class Contract < Dry::Validation::Contract
     include Mortymer::Moldeable
+    include Mortymer::Types
 
     # Exception raised when an error occours in a contract
     class ContractError < StandardError
@@ -20,15 +23,28 @@ module Mortymer
       end
     end
 
+    def self.__internal_struct_repr__
+      @__internal_struct_repr__ || StructCompiler.new.compile(schema.json_schema)
+    end
+
     def self.json_schema
       Generator.new.from_validation(self)
     end
 
     def self.structify(params)
       result = new.call(params)
-      raise ContractError.new(result.errors.to_h) unless result.errors.empty?
+      raise ContractError, result.errors.to_h unless result.errors.empty?
+
+      __internal_struct_repr__.new(**result.to_h)
+    end
 
-      result.to_h
+    def self.compile!
+      # Force eager compilation of the internal struct representation.
+      # This provides an optimization by precompiling the struct when
+      # the class is defined rather than waiting for the first use.
+      # The compilation result is memoized, so subsequent accesses
+      # will reuse the compiled struct.
+      __internal_struct_repr__
     end
   end
 end

data/lib/mortymer/model.rb

@@ -9,14 +9,14 @@ module Mortymer
   # A base model for defining schemas
   class Model < Dry::Struct
     include Mortymer::Moldeable
-    include Dry.Types()
+    include Mortymer::Types
 
     def self.json_schema
       Generator.new.from_struct(self)
     end
 
     def self.structify(params)
-      new(params)
+      call(params)
     end
   end
 end

data/lib/mortymer/sigil.rb

@@ -0,0 +1,92 @@
+# frozen_string_literal: true
+
+module Mortymer
+  # Sigil provides symbolic type checking for input and outputs
+  # of method calls using dry-types
+  module Sigil
+    class TypeError < StandardError; end
+
+    # Class methods to be included as part of the dsl
+    module ClassMethods
+      # Store type signatures for methods before they are defined
+      def sign(*positional_types, returns: nil, **keyword_types)
+        @pending_type_signature = {
+          positional_types: positional_types,
+          keyword_types: keyword_types,
+          returns: returns
+        }
+      end
+
+      # Hook called when a method is defined
+      def method_added(method_name)
+        return super if @pending_type_signature.nil?
+        return super if @processing_type_check
+
+        signature = @pending_type_signature
+        @pending_type_signature = nil
+
+        # Get the original method
+        original_method = instance_method(method_name)
+
+        @processing_type_check = true
+
+        # Redefine the method with type checking
+        define_method(method_name) do |*args, **kwargs|
+          # Validate positional arguments
+          procced_args = []
+          procced_kwargs = {}
+          args.each_with_index do |arg, idx|
+            unless (type = signature[:positional_types][idx])
+              procced_args << arg
+              next
+            end
+
+            begin
+              procced_args << (type.respond_to?(:structify) ? type.structify(arg) : type.call(arg))
+            rescue Dry::Types::CoercionError => e
+              raise TypeError, "Invalid type for argument #{idx}: expected #{type}, got #{arg.class} - #{e.message}"
+            end
+          end
+
+          # Validate keyword arguments
+          kwargs.each do |key, value|
+            unless (type = signature[:keyword_types][key])
+              procced_kwargs[key] = value
+              next
+            end
+
+            begin
+              procced_kwargs[key] = (type.respond_to?(:structify) ? type.structify(value) : type.call(value))
+            rescue Dry::Types::CoercionError => e
+              raise TypeError,
+                    "Invalid type for keyword argument #{key}: expected #{type}, got #{value.class} - #{e.message}"
+            end
+          end
+
+          # Call the original method
+          result = original_method.bind(self).call(*procced_args, **procced_kwargs)
+
+          # Validate return type if specified
+          if (return_type = signature[:returns])
+            begin
+              return return_type.respond_to?(:structify) ? return_type.structify(result) : return_type.call(result)
+            rescue Dry::Types::CoercionError => e
+              raise TypeError, "Invalid return type: expected #{return_type}, got #{result.class} - #{e.message}"
+            end
+          end
+
+          result
+        end
+
+        @processing_type_check = false
+
+        # Call super to maintain compatibility with other method hooks
+        super
+      end
+    end
+
+    def self.included(base)
+      base.extend(ClassMethods)
+    end
+  end
+end

data/lib/mortymer/struct_compiler.rb

@@ -0,0 +1,110 @@
+# frozen_string_literal: true
+
+require "dry-struct"
+require "securerandom"
+
+module Mortymer
+  class StructCompiler
+    PRIMITIVE_TYPE_MAP = {
+      "string" => Mortymer::Model::String,
+      "integer" => Mortymer::Model::Integer,
+      "number" => Mortymer::Model::Float,
+      "boolean" => Mortymer::Model::Bool,
+      "null" => Mortymer::Model::Nil,
+      string: Mortymer::Model::String,
+      integer: Mortymer::Model::Integer,
+      number: Mortymer::Model::Float,
+      boolean: Mortymer::Model::Bool,
+      null: Mortymer::Model::Nil
+    }.freeze
+
+    def initialize(class_name = "GeneratedStruct#{SecureRandom.hex(4)}")
+      @class_name = class_name
+      @types = {}
+    end
+
+    def compile(schema)
+      build_type(schema, @class_name)
+    end
+
+    private
+
+    def build_type(schema, type_name)
+      schema = normalize_schema(schema)
+      case schema["type"]
+      when "object"
+        build_object_type(schema, type_name)
+      when "array"
+        build_array_type(schema)
+      else
+        build_primitive_type(schema)
+      end
+    end
+
+    def normalize_schema(schema)
+      return {} if schema.nil?
+
+      schema = schema.transform_keys(&:to_s)
+      if schema["properties"]
+        schema["properties"] = schema["properties"].transform_keys(&:to_s)
+        schema["properties"].each_value do |prop_schema|
+          normalize_schema(prop_schema)
+        end
+      end
+      schema["items"] = normalize_schema(schema["items"]) if schema["items"]
+      schema["required"] = schema["required"].map(&:to_s) if schema["required"]
+      if schema["enum"]
+        schema["enum"] = schema["enum"].map { |v| v.is_a?(Symbol) ? v.to_s : v }
+      end
+      schema
+    end
+
+    def build_object_type(schema, type_name)
+      return {} unless schema["properties"]
+
+      # Build attribute definitions
+      attributes = schema["properties"].map do |name, property_schema|
+        name = name.to_s # Ensure name is a string
+        nested_type_name = camelize("#{type_name}#{camelize(name)}")
+        type = if property_schema["type"] == "object"
+                 build_type(property_schema, nested_type_name)
+               else
+                 build_type(property_schema, nil)
+               end
+
+        required = schema["required"]&.include?(name)
+        [name, required ? type : type.optional, required]
+      end
+
+      # Create a new Struct class for this object
+      Class.new(Mortymer::Model) do
+        attributes.each do |name, type, required|
+          if required
+            attribute name.to_sym, type
+          else
+            attribute? name.to_sym, type
+          end
+        end
+      end
+    end
+
+    def build_array_type(schema)
+      item_type = build_type(schema["items"], nil)
+      Mortymer::Model::Array.of(item_type)
+    end
+
+    def build_primitive_type(schema)
+      type_class = PRIMITIVE_TYPE_MAP[schema["type"]] || Mortymer::Model::Any
+
+      if schema["enum"]
+        type_class.enum(*schema["enum"])
+      else
+        type_class
+      end
+    end
+
+    def camelize(string)
+      string.split(/[^a-zA-Z0-9]/).map(&:capitalize).join
+    end
+  end
+end

data/lib/mortymer/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Mortymer
-  VERSION = "0.0.9"
+  VERSION = "0.0.11"
 end

data/lib/mortymer.rb

@@ -2,6 +2,8 @@
 # typed: true
 
 require "dry/struct"
+require "dry/schema"
+Dry::Schema.load_extensions(:json_schema)
 require "mortymer/types"
 require "mortymer/uploaded_file"
 require "mortymer/uploaded_files"
@@ -18,5 +20,7 @@ require "mortymer/openapi_generator"
 require "mortymer/container"
 require "mortymer/dependencies_dsl"
 require "mortymer/security_schemes"
+require "mortymer/struct_compiler"
+require "mortymer/sigil"
 require "mortymer/rails" if defined?(Rails)
 require "mortymer/railtie" if defined?(Rails::Railtie)

metadata

@@ -1,13 +1,13 @@
 --- !ruby/object:Gem::Specification
 name: mortymer
 version: !ruby/object:Gem::Version
-  version: 0.0.9
+  version: 0.0.11
 platform: ruby
 authors:
 - Adrian Gonzalez
 bindir: exe
 cert_chain: []
-date: 2025-03-20 00:00:00.000000000 Z
+date: 2025-03-31 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: dry-struct
@@ -90,8 +90,10 @@ files:
 - docs/advanced/openapi.md
 - docs/assets/swagg.png
 - docs/guide/api-metadata.md
+- docs/guide/dependency-injection.md
 - docs/guide/introduction.md
 - docs/guide/models.md
+- docs/guide/mortymer-dependency-injection.md
 - docs/guide/quick-start.md
 - docs/index.md
 - lib/mortymer.rb
@@ -113,6 +115,8 @@ files:
 - lib/mortymer/rails/routes.rb
 - lib/mortymer/railtie.rb
 - lib/mortymer/security_schemes.rb
+- lib/mortymer/sigil.rb
+- lib/mortymer/struct_compiler.rb
 - lib/mortymer/types.rb
 - lib/mortymer/uploaded_file.rb
 - lib/mortymer/uploaded_files.rb